From: Starlink
[mailto:starlink-bounces@lists.bufferbloat.net] On Behalf Of David P. Reed
Sent: Friday, July 9, 2021 11:40
AM
To: starlink@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
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.