[Starlink] Starlink and bufferbloat status?

[Dick Roy]

  _____  

From: Starlink [mailto:starlink-bounces at lists.bufferbloat.net] On Behalf Of
David P. Reed
Sent: Friday, July 9, 2021 11:40 AM
To: starlink at lists.bufferbloat.net
Subject: [Starlink] Starlink and bufferbloat status?

 

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. 

[RR] So you are saying Musk might have used "artistic license" to get a
license out of the FCC??/ Shocking!  Never heard that before!  I thought
everyone simply told the FCC the truth and got licenses based on technical
merit, not marketing BS! Well, as the old saying goes: "If you can't dazzle
them with your brilliance, baffle them with your bullshit!"

 

:^))))

 

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.

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20210709/e0a0882c/attachment.html>