I'm giving Dave a wireguard link and root on my off-grid host (which is recoverable with PiKVM unless the hardware fails). It's in the container in the photo.[image: Macdoel.jpg] On Mon, Sep 26, 2022 at 2:28 PM warren ponder via Starlink < starlink@lists.bufferbloat.net> wrote: > Dave what do you need in order to add sites to the data collection. Feel > free to reply separate or link to a previous thread > > Thx > > WP > > On Mon, Sep 26, 2022, 2:10 PM Dave Taht via Starlink < > starlink@lists.bufferbloat.net> wrote: > >> I tend to cite rfc7567 (published 2015) a lot, which replaces rfc2309 >> (published 1992!). >> >> Thing is, long before that, I'd come to the conclusion that fair >> queuing was a requirement for >> sustaining the right throughput for low rate flows in wildly variable >> bandwidth. At certain places in >> LTE/5g/starlink networks the payload is encrypted and the header info >> required unavailable, and my advocacy of fq is certainly not shared by >> everyone. >> >> We don't know enough about the actual points of congestion in starlink >> to know if fq could be applied, >> and although aqm is a very good idea everywhere, is also largely >> undeployed where it would matter most. >> >> I focused my initial analysis of starlink on just uplink congestion, >> which I believe can be easily improved given about 20 minutes with a >> cross compiler for the dishy. We have a very good proof of concept as >> to how to improve starlinks behavior over here: >> https://forum.openwrt.org/t/cake-w-adaptive-bandwidth/135379/87 and >> ironically the same script could be run on their router as it is based >> on a 6 year old version of openwrt in the first place. >> >> I have plenty of data later than this ( >> >> https://docs.google.com/document/d/1puRjUVxJ6cCv-rgQ_zn-jWZU9ae0jZbFATLf4PQKblM/edit >> ) but I would like to be collecting it from at least six sites around >> the world. >> >> On Mon, Sep 26, 2022 at 1:54 PM Eugene Y Chang via Starlink >> wrote: >> > >> > Ok, we are getting into the details. I agree. >> > >> > Every node in the path has to implement this to be effective. >> > In fact, every node in the path has to have the same prioritization or >> the scheme becomes ineffective. >> > >> > Gene >> > ---------------------------------------------- >> > Eugene Chang >> > IEEE Senior Life Member >> > eugene.chang@ieee.org >> > 781-799-0233 (in Honolulu) >> > >> > >> > >> > On Sep 26, 2022, at 10:48 AM, David Lang wrote: >> > >> > software updates can do far more than just improve recovery. >> > >> > In practice, large data transfers are less sensitive to latency than >> smaller data transfers (i.e. downloading a CD image vs a video conference), >> software can ensure better fairness in preventing a bulk transfer from >> hurting the more latency sensitive transfers. >> > >> > (the example below is not completely accurate, but I think it gets the >> point across) >> > >> > When buffers become excessivly large, you have the situation where a >> video call is going to generate a small amount of data at a regular >> interval, but a bulk data transfer is able to dump a huge amount of data >> into the buffer instantly. >> > >> > If you just do FIFO, then you get a small chunk of video call, then >> several seconds worth of CD transfer, followed by the next small chunk of >> the video call. >> > >> > But the software can prevent the one app from hogging so much of the >> connection and let the chunk of video call in sooner, avoiding the impact >> to the real time traffic. Historically this has required the admin classify >> all traffic and configure equipment to implement different treatment based >> on the classification (and this requires trust in the classification >> process), the bufferbloat team has developed options (fq_codel and cake) >> that can ensure fairness between applications/servers with little or no >> configuration, and no trust in other systems to properly classify their >> traffic. >> > >> > The one thing that Cake needs to work really well is to be able to know >> what the data rate available is. With Starlink, this changes frequently and >> cake integrated into the starlink dish/router software would be far better >> than anything that can be done externally as the rate changes can be fed >> directly into the settings (currently they are only indirectly detected) >> > >> > David Lang >> > >> > >> > On Mon, 26 Sep 2022, Eugene Y Chang via Starlink wrote: >> > >> > You already know this. Bufferbloat is a symptom and not the cause. >> Bufferbloat grows when there are (1) periods of low or no bandwidth or (2) >> periods of insufficient bandwidth (aka network congestion). >> > >> > If I understand this correctly, just a software update cannot make >> bufferbloat go away. It might improve the speed of recovery (e.g. throw >> away all time sensitive UDP messages). >> > >> > Gene >> > ---------------------------------------------- >> > Eugene Chang >> > IEEE Senior Life Member >> > eugene.chang@ieee.org >> > 781-799-0233 (in Honolulu) >> > >> > >> > >> > On Sep 26, 2022, at 10:04 AM, Bruce Perens wrote: >> > >> > Please help to explain. Here's a draft to start with: >> > >> > Starlink Performance Not Sufficient for Military Applications, Say >> Scientists >> > >> > The problem is not availability: Starlink works where nothing but >> another satellite network would. It's not bandwidth, although others have >> questions about sustaining bandwidth as the customer base grows. It's >> latency and jitter. As load increases, latency, the time it takes for a >> packet to get through, increases more than it should. The scientists who >> have fought bufferbloat, a major cause of latency on the internet, know >> why. SpaceX needs to upgrade their system to use the scientist's Open >> Source modifications to Linux to fight bufferbloat, and thus reduce >> latency. This is mostly just using a newer version, but there are some >> tunable parameters. Jitter is a change in the speed of getting a packet >> through the network during a connection, which is inevitable in satellite >> networks, but will be improved by making use of the bufferbloat-fighting >> software, and probably with the addition of more satellites. >> > >> > We've done all of the work, SpaceX just needs to adopt it by upgrading >> their software, said scientist Dave Taht. Jim Gettys, Taht's collaborator >> and creator of the X Window System, chimed in: >> > Open Source luminary Bruce Perens said: sometimes Starlink's latency >> and jitter make it inadequate to remote-control my ham radio station. But >> the military is experimenting with remote-control of vehicles on the >> battlefield and other applications that can be demonstrated, but won't >> happen at scale without adoption of bufferbloat-fighting strategies. >> > >> > On Mon, Sep 26, 2022 at 12:59 PM Eugene Chang < >> eugene.chang@alum.mit.edu> wrote: >> > The key issue is most people don’t understand why latency matters. They >> don’t see it or feel it’s impact. >> > >> > First, we have to help people see the symptoms of latency and how it >> impacts something they care about. >> > - gamers care but most people may think it is frivolous. >> > - musicians care but that is mostly for a hobby. >> > - business should care because of productivity but they don’t know how >> to “see” the impact. >> > >> > Second, there needs to be a “OMG, I have been seeing the action of >> latency all this time and never knew it! I was being shafted.” Once you >> have this awakening, you can get all the press you want for free. >> > >> > Most of the time when business apps are developed, “we” hide the impact >> of poor performance (aka latency) or they hide from the discussion because >> the developers don’t have a way to fix the latency. Maybe businesses don’t >> care because any employees affected are just considered poor performers. >> (In bad economic times, the poor performers are just laid off.) For >> employees, if they happen to be at a location with bad latency, they don’t >> know that latency is hurting them. Unfair but most people don’t know the >> issue is latency. >> > >> > Talking and explaining why latency is bad is not as effective as >> showing why latency is bad. Showing has to be with something that has a >> person impact. >> > >> > Gene >> > ----------------------------------- >> > Eugene Chang >> > eugene.chang@alum.mit.edu >> > +1-781-799-0233 (in Honolulu) >> > >> > >> > >> > >> > >> > On Sep 26, 2022, at 6:32 AM, Bruce Perens via Starlink < >> starlink@lists.bufferbloat.net> >> wrote: >> > >> > If you want to get attention, you can get it for free. I can place >> articles with various press if there is something interesting to say. Did >> this all through the evangelism of Open Source. All we need to do is write, >> sign, and publish a statement. What they actually write is less relevant if >> they publish a link to our statement. >> > >> > Right now I am concerned that the Starlink latency and jitter is going >> to be a problem even for remote controlling my ham station. The US Military >> is interested in doing much more, which they have demonstrated, but I don't >> see happening at scale without some technical work on the network. Being >> able to say this isn't ready for the government's application would be an >> attention-getter. >> > >> > Thanks >> > >> > Bruce >> > >> > On Mon, Sep 26, 2022 at 9:21 AM Dave Taht via Starlink < >> starlink@lists.bufferbloat.net> >> wrote: >> > These days, if you want attention, you gotta buy it. A 50k half page >> > ad in the wapo or NYT riffing off of It's the latency, Stupid!", >> > signed by the kinds of luminaries we got for the fcc wifi fight, would >> > go a long way towards shifting the tide. >> > >> > On Mon, Sep 26, 2022 at 8:29 AM Dave Taht > dave.taht@gmail.com>> wrote: >> > >> > >> > On Mon, Sep 26, 2022 at 8:20 AM Livingood, Jason >> > > >> wrote: >> > >> > >> > The awareness & understanding of latency & impact on QoE is nearly >> unknown among reporters. IMO maybe there should be some kind of background >> briefings for reporters - maybe like a simple YouTube video explainer that >> is short & high level & visual? Otherwise reporters will just continue to >> focus on what they know... >> > >> > >> > That's a great idea. I have visions of crashing the washington >> > correspondents dinner, but perhaps >> > there is some set of gatherings journalists regularly attend? >> > >> > >> > On 9/21/22, 14:35, "Starlink on behalf of Dave Taht via Starlink" < >> starlink-bounces@lists.bufferbloat.net > starlink-bounces@lists.bufferbloat.net> on behalf of >> starlink@lists.bufferbloat.net > >> wrote: >> > >> > I still find it remarkable that reporters are still missing the >> > meaning of the huge latencies for starlink, under load. >> > >> > >> > >> > >> > -- >> > FQ World Domination pending: >> https://blog.cerowrt.org/post/state_of_fq_codel/< >> https://blog.cerowrt.org/post/state_of_fq_codel/> >> > Dave Täht CEO, TekLibre, LLC >> > >> > >> > >> > >> > -- >> > FQ World Domination pending: >> https://blog.cerowrt.org/post/state_of_fq_codel/< >> https://blog.cerowrt.org/post/state_of_fq_codel/> >> > Dave Täht CEO, TekLibre, LLC >> > _______________________________________________ >> > Starlink mailing list >> > Starlink@lists.bufferbloat.net >> > https://lists.bufferbloat.net/listinfo/starlink < >> https://lists.bufferbloat.net/listinfo/starlink> >> > >> > >> > -- >> > Bruce Perens K6BP >> > _______________________________________________ >> > Starlink mailing list >> > Starlink@lists.bufferbloat.net >> > https://lists.bufferbloat.net/listinfo/starlink < >> https://lists.bufferbloat.net/listinfo/starlink> >> > >> > >> > >> > >> > -- >> > Bruce Perens K6BP >> > >> > >> > _______________________________________________ >> > Starlink mailing list >> > Starlink@lists.bufferbloat.net >> > https://lists.bufferbloat.net/listinfo/starlink >> >> >> >> -- >> FQ World Domination pending: >> https://blog.cerowrt.org/post/state_of_fq_codel/ >> Dave Täht CEO, TekLibre, LLC >> _______________________________________________ >> Starlink mailing list >> Starlink@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/starlink >> > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink > -- Bruce Perens K6BP