<div dir="ltr"><div><br>Elon said "foolish packet routing" for things over 20ms! Which seems crazy if you do some basic math:<br><ul><li>Sat to User Terminal distance: 550-950km air/vacuum: 1.9 - 3.3ms</li><li>Sat to GW distance: 550-950km air/vacuum: 1.9 - 3.3ms</li><li>GW to PoP Distance: 50-800km fiber: 0.25 - 4ms</li><li>PoP to Internet Distance: 50km fiber: 0.25 - 0.5ms</li><li>Total one-way delay: 4.3 - 11.1ms</li><li>Theoretical minimum RTT: 8.6ms - 22.2ms, call it 15.4ms </li></ul><div>This includes no transmission delay, queuing delay, processing/fragmentation/reassembly/etc, and no time-division multiplexing.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 16, 2021 at 10:09 AM David Lang <<a href="mailto:david@lang.hm">david@lang.hm</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think it depends on if you are looking at datacenter-to-datacenter latency of <br>
home to remote datacenter latency :-)<br>
<br>
my rule of thumb for cross US ping time has been 80-100ms latency (but it's been <br>
a few years since I tested it).<br>
<br>
I note that an article I saw today said that Elon is saying that latency will <br>
improve significantly in the near future, that up/down latency is ~20ms and the <br>
additional delays pushing it to the 80ms range are 'stupid packet routing' <br>
problems that they are working on.<br>
<br>
If they are still in that level of optimization, it doesn't surprise me that <br>
they haven't really focused on the bufferbloat issue, they have more obvious <br>
stuff to fix first.<br>
<br>
David Lang<br>
<br>
<br>
  On Fri, 16 Jul 2021, Wheelock, Ian wrote:<br>
<br>
> Date: Fri, 16 Jul 2021 10:21:52 +0000<br>
> From: "Wheelock, Ian" <<a href="mailto:ian.wheelock@commscope.com" target="_blank">ian.wheelock@commscope.com</a>><br>
> To: David Lang <<a href="mailto:david@lang.hm" target="_blank">david@lang.hm</a>>, David P. Reed <<a href="mailto:dpreed@deepplum.com" target="_blank">dpreed@deepplum.com</a>><br>
> Cc: "<a href="mailto:starlink@lists.bufferbloat.net" target="_blank">starlink@lists.bufferbloat.net</a>" <<a href="mailto:starlink@lists.bufferbloat.net" target="_blank">starlink@lists.bufferbloat.net</a>><br>
> Subject: Re: [Starlink] Starlink and bufferbloat status?<br>
> <br>
> Hi David<br>
> In terms of the Latency that David (Reed) mentioned for California to Massachusetts of about 17ms over the public internet, it seems a bit faster than what I would expect. My own traceroute via my VDSL link shows 14ms just to get out of the operator network.<br>
><br>
> <a href="https://www.wondernetwork.com" rel="noreferrer" target="_blank">https://www.wondernetwork.com</a>  is a handy tool for checking geographic ping perf between cities, and it shows a min of about 66ms for pings between Boston and San Diego <a href="https://wondernetwork.com/pings/boston/San%20Diego" rel="noreferrer" target="_blank">https://wondernetwork.com/pings/boston/San%20Diego</a> (so about 33ms for 1-way transfer).<br>
><br>
> Distance wise this is about 4,100 KM (2,500 M), and @2/3 speed of light (through a pure fibre link of that distance) the propagation time is just over 20ms. If the network equipment between the Boston and San Diego is factored in, with some buffering along the way, 33ms does seem quite reasonable over the 20ms for speed of light in fibre for that 1-way transfer<br>
><br>
> -Ian Wheelock<br>
><br>
> From: Starlink <<a href="mailto:starlink-bounces@lists.bufferbloat.net" target="_blank">starlink-bounces@lists.bufferbloat.net</a>> on behalf of David Lang <<a href="mailto:david@lang.hm" target="_blank">david@lang.hm</a>><br>
> Date: Friday 9 July 2021 at 23:59<br>
> To: "David P. Reed" <<a href="mailto:dpreed@deepplum.com" target="_blank">dpreed@deepplum.com</a>><br>
> Cc: "<a href="mailto:starlink@lists.bufferbloat.net" target="_blank">starlink@lists.bufferbloat.net</a>" <<a href="mailto:starlink@lists.bufferbloat.net" target="_blank">starlink@lists.bufferbloat.net</a>><br>
> Subject: Re: [Starlink] Starlink and bufferbloat status?<br>
><br>
> IIRC, the definition of 'low latency' for the FCC was something like 100ms, and Musk was predicting <40ms. roughly competitive with landlines, and worlds better than geostationary satellite (and many<br>
> External (mailto:<a href="mailto:david@lang.hm" target="_blank">david@lang.hm</a>)<br>
>   <a href="https://shared.outlook.inky.com/report?id=Y29tbXNjb3BlL2lhbi53aGVlbG9ja0Bjb21tc2NvcGUuY29tL2I1MzFjZDA4OTZmMWI0Yzc5NzdiOTIzNmY3MTAzM2MxLzE2MjU4NzE1NDkuNjU=#key=19e8545676e28e577c813de83a4cf1dc" rel="noreferrer" target="_blank">https://shared.outlook.inky.com/report?id=Y29tbXNjb3BlL2lhbi53aGVlbG9ja0Bjb21tc2NvcGUuY29tL2I1MzFjZDA4OTZmMWI0Yzc5NzdiOTIzNmY3MTAzM2MxLzE2MjU4NzE1NDkuNjU=#key=19e8545676e28e577c813de83a4cf1dc</a>  <a href="https://www.inky.com/banner-faq/" rel="noreferrer" target="_blank">https://www.inky.com/banner-faq/</a>  <a href="https://www.inky.com" rel="noreferrer" target="_blank">https://www.inky.com</a><br>
><br>
> IIRC, the definition of 'low latency' for the FCC was something like 100ms, and<br>
> Musk was predicting <40ms.<br>
>  <br>
> roughly competitive with landlines, and worlds better than geostationary<br>
> satellite (and many wireless ISPs)<br>
>  <br>
> but when doing any serious testing of latency, you need to be wired to the<br>
> router, wifi introduces so much variability that it swamps the signal.<br>
>  <br>
> David Lang<br>
>  <br>
> On Fri, 9 Jul 2021, David P. Reed wrote:<br>
>  <br>
>> Date: Fri, 9 Jul 2021 14:40:01 -0400 (EDT)<br>
>> From: David P. Reed <<a href="mailto:dpreed@deepplum.com" target="_blank">dpreed@deepplum.com</a>><br>
>> To: <a href="mailto:starlink@lists.bufferbloat.net" target="_blank">starlink@lists.bufferbloat.net</a><br>
>> Subject: [Starlink] Starlink and bufferbloat status?<br>
>><br>
>><br>
>> Early measurements of performance of Starlink have shown significant bufferbloat, as Dave Taht has shown.<br>
>><br>
>> 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,<br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> 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)<br>
>><br>
>> 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.<br>
>><br>
>><br>
>> 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.<br>
> _______________________________________________<br>
> Starlink mailing list<br>
> <a href="mailto:Starlink@lists.bufferbloat.net" target="_blank">Starlink@lists.bufferbloat.net</a><br>
> <a href="https://secure-web.cisco.com/1sNc_-1HhGCW7xdirt_lAoAy5Nn5T6UA85Scjn5BR7QHXtumhrf6RKn78SuRJG7DUKI3duggU9g6hJKW-Ze07HTczYqB9mBpIeALqk5drQ7nMvM8K7JbWfUbPR7JSNrI75UjiNXQk0wslBfoOTvkMlRj5eMOZhps7DMGBRQTVAeTd5vwXoQtDgS6zLCcJkrcO2S9MRSCC4f1I17SzgQJIwqo3LEwuN6lD-pkX0MFLqGr2zzsHw5eapd-VBlHu5reC4-OEn2zHkb7HNzS1pcueF6tsUE1vFRsWs2SIOwU5MvbKe3J3Q6NRQ40cHI1AGd-i/https://lists.bufferbloat.net/listinfo/starlink" rel="noreferrer" target="_blank">https://secure-web.cisco.com/1sNc_-1HhGCW7xdirt_lAoAy5Nn5T6UA85Scjn5BR7QHXtumhrf6RKn78SuRJG7DUKI3duggU9g6hJKW-Ze07HTczYqB9mBpIeALqk5drQ7nMvM8K7JbWfUbPR7JSNrI75UjiNXQk0wslBfoOTvkMlRj5eMOZhps7DMGBRQTVAeTd5vwXoQtDgS6zLCcJkrcO2S9MRSCC4f1I17SzgQJIwqo3LEwuN6lD-pkX0MFLqGr2zzsHw5eapd-VBlHu5reC4-OEn2zHkb7HNzS1pcueF6tsUE1vFRsWs2SIOwU5MvbKe3J3Q6NRQ40cHI1AGd-i/https://lists.bufferbloat.net/listinfo/starlink</a><br>
><br>
>_______________________________________________<br>
Starlink mailing list<br>
<a href="mailto:Starlink@lists.bufferbloat.net" target="_blank">Starlink@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/starlink" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/starlink</a><br>
</blockquote></div>