Pick up the glove? I can be part of a team. I am not as close as to the equipment as I used to be. I need help assembling a demo configuration that can engage the subscribers. Building a local team for this has been very slow going.
I like helping a market #3 or #4 disrupt an incumbent. In most cases I have
seen, the #2 already has a game plan for competing with #1. A distant #3 is
usually the most hungry.
Gene.
----------------------------------------------
Eugene Chang
IEEE Life Senior Member
IEEE Communications Society & Signal Processing Society,
Hawaii Chapter Chair
IEEE Life Member Affinity Group Hawaii Chair
IEEE Entrepreneurship, Mentor
eugene.ch...@ieee.org
m 781-799-0233 (in Honolulu)
> On Apr 30, 2024, at 9:27 PM, Frantisek Borsik <frantisek.bor...@gmail.com>
> wrote:
>
> Basically, Eugene, the situation you are describing is calling for a
> competitor to disrupt them!
>
> This is such an old story - so many ISPs, especially WIPSs, started just
> because they either didn't have any option or all those options available
> were really terrible.
>
> Don't you want to pick up the glove? :P
>
> All the best,
>
> Frank
>
> Frantisek (Frank) Borsik
>
>
>
> https://www.linkedin.com/in/frantisekborsik
> <https://www.linkedin.com/in/frantisekborsik>
> Signal, Telegram, WhatsApp: +421919416714
>
> iMessage, mobile: +420775230885
>
> Skype: casioa5302ca
>
> frantisek.bor...@gmail.com <mailto:frantisek.bor...@gmail.com>
>
> On Tue, Apr 30, 2024 at 11:53 PM Eugene Y Chang <eugene.ch...@ieee.org
> <mailto:eugene.ch...@ieee.org>> wrote:
> Frank,
> Thank you. What you suggest makes sense if it was objective!
>
> In my neighborhood, the ISP’s organization will feel they have nothing to
> learn from outsiders. (Worst, both major ISPs are just a subsidiary of
> another organization. They just implement corporate standards. The local
> managers are not motivated to deviate from their corporate marching orders.)
>
> A public promotion (campaign) of modern best practices is needed. Then I need
> to have this campaign spill over to the subscriber community. The business
> community needs to be educated that their productivity will improve. The
> social leaders need to learn that their community will get better service.
> Then, and only then, can I see the ISP feeling the need to improve. It helps
> if the improvement is just open-source software on their hardware investment.
>
>
> Gene
> ----------------------------------------------
> Eugene Chang
> IEEE Life Senior Member
>
>
>
>> On Apr 30, 2024, at 11:35 AM, Frantisek Borsik <frantisek.bor...@gmail.com
>> <mailto:frantisek.bor...@gmail.com>> wrote:
>>
>> Eugene - the easiest thing in the case of your ISP would be tell him about
>> us: https://libreqos.io <https://libreqos.io/>
>>
>> He can take a look on it, join our support chat and get help if he won't be
>> able to get it up and running:
>> https://chat.libreqos.io/join/fvu3cerayyaumo377xwvpev6/
>> <https://chat.libreqos.io/join/fvu3cerayyaumo377xwvpev6/>
>>
>> But most of the ISPs don't need to talk with us at all, it's easy to deploy.
>>
>>
>> All the best,
>>
>> Frank
>>
>> Frantisek (Frank) Borsik
>>
>>
>>
>> https://www.linkedin.com/in/frantisekborsik
>> <https://www.linkedin.com/in/frantisekborsik>
>> Signal, Telegram, WhatsApp: +421919416714
>>
>> iMessage, mobile: +420775230885
>>
>> Skype: casioa5302ca
>>
>> frantisek.bor...@gmail.com <mailto:frantisek.bor...@gmail.com>
>>
>> On Tue, Apr 30, 2024 at 11:22 PM Eugene Y Chang via Starlink
>> <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>>
>> wrote:
>> OK. I need help teaching my ISPs that they can do this without threatening
>> their business model.
>> Who can help me?
>>
>> A public demo? Yes! Are you saying that if our (my) neighborhood ISP adopted
>> the lessons from the public demo, most of the latency issues would be
>> solved? What won’t get fixed? How do we make this a widely adopted best
>> practice? Am I crying over issues that are already fixed? Does this simplify
>> the issues at the FCC?
>>
>> Gene
>> ----------------------------------------------
>> Eugene Chang
>> IEEE Life Senior Member
>>
>>
>>
>>
>>> On Apr 30, 2024, at 11:07 AM, Dave Taht <dave.t...@gmail.com
>>> <mailto:dave.t...@gmail.com>> wrote:
>>>
>>> Just fq codel or cake everything and you get all that.
>>>
>>> Libreqos is free software for those that do not want to update their data
>>> plane. Perhaps we should do a public demo of what it can do for every tech
>>> on the planet. Dsl benefits, fiber does also (but it is the stats that
>>> matter more on fiber because the customer wifi becomes bloated)
>>>
>>> Starlink merely fq codeled their wifi and did some aqm work (not codel I
>>> think) to get the amazing results they are getting today. I don't have the
>>> waveform test results handy but they are amazing. I feel a sea change in
>>> the wind...
>>>
>>>
>>>
>>> On Tue, Apr 30, 2024, 12:51 PM Eugene Y Chang via Starlink
>>> <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>>
>>> wrote:
>>> Colin,
>>> I am overwhelmed with all the reasons that prevent low(er) or consistent
>>> latency.
>>> I think that our best ISP offerings should deliver graceful, agile, or
>>> nimble service. Sure, handle all the high-volume data. The high-volume
>>> service just shouldn’t preclude graceful service. Yes, the current ISP
>>> practices fall short. Can we help them improve their service?
>>>
>>> Am I asking too much?
>>>
>>> Gene
>>> ----------------------------------------------
>>> Eugene Chang
>>> IEEE Life Senior Member
>>>
>>>
>>>
>>>
>>>> On Apr 30, 2024, at 9:31 AM, Colin_Higbie via Starlink
>>>> <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>>
>>>> wrote:
>>>>
>>>> Gene,
>>>>
>>>> I think the lion's share of other people (many brilliant people here) on
>>>> this thread are focused on keeping latency down when under load. I
>>>> generally just read and don't contribute on those discussions, because
>>>> that's not my area of expertise. I only posted my point on bandwidth, not
>>>> to detract from the importance of reducing latency, but to correct what I
>>>> believed to be an important error on minimum bandwidth required to be able
>>>> to perform standard Internet functions.
>>>>
>>>> To my surprise, there was pushback on the figure, so I've responded to try
>>>> to educate this group on streaming usage in the hope that the people
>>>> working on the latency problem under load (core reason for this group to
>>>> exist) can also be aware of the minimum bandwidth needs to ensure they
>>>> don't plan based on bad assumptions.
>>>>
>>>> For a single user, minimum bandwidth (independent of latency) needs to be
>>>> at least 25Mbps assuming the goal is to provide access to all standard
>>>> Internet services. Anything short of that will deny users access to the
>>>> primary streaming services, and more specifically won't be able to watch
>>>> 4K HDR video, which is the market standard for streaming services today
>>>> and likely will remain at that level for the next several years.
>>>>
>>>> I think it's fine to offer lower-cost options that don't deliver 4K HDR
>>>> video (not everyone cares about that), but at least 25Mbps should be
>>>> available to an Internet customer for any new Internet service rollout.
>>>>
>>>> Cheers,
>>>> Colin
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Starlink <starlink-boun...@lists.bufferbloat.net
>>>> <mailto:starlink-boun...@lists.bufferbloat.net>> On Behalf Of
>>>> starlink-requ...@lists.bufferbloat.net
>>>> <mailto:starlink-requ...@lists.bufferbloat.net>
>>>> Sent: Tuesday, April 30, 2024 3:05 PM
>>>> To: starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>
>>>> Subject: Starlink Digest, Vol 37, Issue 15
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>>
>>>> Message: 1
>>>> Date: Tue, 30 Apr 2024 09:04:43 -1000
>>>> From: Eugene Y Chang <eugene.ch...@ieee.org <mailto:eugene.ch...@ieee.org>>
>>>> To: Colin_Higbie <chigb...@higbie.name <mailto:chigb...@higbie.name>>,
>>>> Dave Taht via Starlink
>>>> <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>>
>>>> Subject: Re: [Starlink] It’s the Latency, FCC
>>>> Message-ID: <438b1bc4-d465-497a-b6ba-700e1d411...@ieee.org
>>>> <mailto:438b1bc4-d465-497a-b6ba-700e1d411...@ieee.org>>
>>>> Content-Type: text/plain; charset="utf-8"
>>>>
>>>> I am always surprised how complicated these discussions become. (Surprised
>>>> mostly because I forgot the kind of issues this community care about.) The
>>>> discussion doesn’t shed light on the following scenarios.
>>>>
>>>> While watching stream content, activating controls needed to switch
>>>> content sometimes (often?) have long pauses. I attribute that to buffer
>>>> bloat and high latency.
>>>>
>>>> With a happy household user watching streaming media, a second user could
>>>> have terrible shopping experience with Amazon. The interactive response
>>>> could be (is often) horrible. (Personally, I would be doing email and
>>>> working on a shared doc. The Amazon analogy probably applies to more
>>>> people.)
>>>>
>>>> How can we deliver graceful performance to both persons in a household?
>>>> Is seeking graceful performance too complicated to improve?
>>>> (I said “graceful” to allow technical flexibility.)
>>>>
>>>> Gene
>>>> ----------------------------------------------
>>>> Eugene Chang
>>>>
>>>> _______________________________________________
>>>> Starlink mailing list
>>>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>>>> https://lists.bufferbloat.net/listinfo/starlink
>>>> <https://lists.bufferbloat.net/listinfo/starlink>
>>>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>>> https://lists.bufferbloat.net/listinfo/starlink
>>> <https://lists.bufferbloat.net/listinfo/starlink>
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>> https://lists.bufferbloat.net/listinfo/starlink
>> <https://lists.bufferbloat.net/listinfo/starlink>
>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Starlink mailing list Starlink@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/starlink
