[Starlink] Starlink and bufferbloat status?

[Nathan Owens]

I haven't done detailed testing, but anecdotally, there haven't been any
changes I've noticed. A few times, it's seemed worse, with latency
increasing to 700-900ms for several seconds after starting an upload,
before returning to ~30-150ms.

On Fri, Jul 9, 2021 at 11:40 AM David P. Reed <dpreed at deepplum.com> wrote:

> Early measurements of performance of Starlink have shown significant
> bufferbloat, as Dave Taht has shown.
>
>
>
> But...  Starlink is a moving target. The bufferbloat isn't a hardware
> issue, it should be completely manageable, starting by simple firmware
> changes inside the Starlink system itself. For example, implementing
> fq_codel so that bottleneck links just drop packets according to the Best
> Practices RFC,
>
>
>
> So I'm hoping this has improved since Dave's measurements. How much has it
> improved? What's the current maximum packet latency under full load,  Ive
> heard anecdotally that a friend of a friend gets 84 msec. *ping times under
> full load*, but he wasn't using flent or some other measurement tool of
> good quality that gives a true number.
>
>
>
> 84 msec is not great - it's marginal for Zoom quality experience (you want
> latencies significantly less than 100 msec. as a rule of thumb for
> teleconferencing quality). But it is better than Dave's measurements showed.
>
>
>
> Now Musk bragged that his network was "low latency" unlike other high
> speed services, which means low end-to-end latency.  That got him
> permission from the FCC to operate Starlink at all. His number was, I
> think, < 5 msec. 84 is a lot more than 5. (I didn't believe 5, because he
> probably meant just the time from the ground station to the terminal
> through the satellite. But I regularly get 17 msec. between California and
> Massachusetts over the public Internet)
>
>
>
> So 84 might be the current status. That would mean that someone at
> Srarlink might be paying some attention, but it is a long way from what
> Musk implied.
>
>
>
>
>
> PS: I forget the number of the RFC, but the number of packets queued on an
> egress link should be chosen by taking the hardware bottleneck throughput
> of any path, combined with an end-to-end Internet underlying delay of about
> 10 msec. to account for hops between source and destination. Lets say
> Starlink allocates 50 Mb/sec to each customer, packets are limited to
> 10,000 bits (1500 * 8), so the outbound queues should be limited to about
> 0.01 * 50,000,000 / 10,000, which comes out to about 250 packets from each
> terminal of buffering, total, in the path from terminal to public Internet,
> assuming the connection to the public Internet is not a problem.
>
>
>
>
> _______________________________________________
> Starlink mailing list
> Starlink at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20210709/0f58fc6c/attachment.html>