From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp82.iad3a.emailsrvr.com (smtp82.iad3a.emailsrvr.com [173.203.187.82]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 415A43CB35 for ; Fri, 9 Jul 2021 14:40:02 -0400 (EDT) Received: from app50.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp35.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id CB8BE5AAB; Fri, 9 Jul 2021 14:40:01 -0400 (EDT) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app50.wa-webapps.iad3a (Postfix) with ESMTP id B76C7600BC; Fri, 9 Jul 2021 14:40:01 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Fri, 9 Jul 2021 14:40:01 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Fri, 9 Jul 2021 14:40:01 -0400 (EDT) From: "David P. Reed" To: starlink@lists.bufferbloat.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20210709144001000000_34494" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: X-Client-IP: 209.6.168.128 Message-ID: <1625856001.74681750@apps.rackspace.com> X-Mailer: webmail/19.0.7-RC X-Classification-ID: 0a40f3ce-5244-41bc-9869-92ca51e5bf26-1-1 Subject: [Starlink] =?utf-8?q?Starlink_and_bufferbloat_status=3F?= X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 18:40:02 -0000 ------=_20210709144001000000_34494 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AEarly measurements of performance of Starlink have shown significant buf= ferbloat, as Dave Taht has shown.=0A =0ABut... Starlink is a moving target= . The bufferbloat isn't a hardware issue, it should be completely manageabl= e, starting by simple firmware changes inside the Starlink system itself. F= or example, implementing fq_codel so that bottleneck links just drop packet= s according to the Best Practices RFC,=0A =0ASo I'm hoping this has improve= d since Dave's measurements. How much has it improved? What's the current m= aximum 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 usin= g flent or some other measurement tool of good quality that gives a true nu= mber.=0A =0A84 msec is not great - it's marginal for Zoom quality experienc= e (you want latencies significantly less than 100 msec. as a rule of thumb = for teleconferencing quality). But it is better than Dave's measurements sh= owed.=0A =0ANow Musk bragged that his network was "low latency" unlike othe= r high speed services, which means low end-to-end latency. That got him pe= rmission 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 sa= tellite. But I regularly get 17 msec. between California and Massachusetts = over the public Internet)=0A =0ASo 84 might be the current status. That wou= ld mean that someone at Srarlink might be paying some attention, but it is = a long way from what Musk implied.=0A =0A =0APS: I forget the number of the= RFC, but the number of packets queued on an egress link should be chosen b= y taking the hardware bottleneck throughput of any path, combined with an e= nd-to-end Internet underlying delay of about 10 msec. to account for hops b= etween source and destination. Lets say Starlink allocates 50 Mb/sec to eac= h 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 o= ut to about 250 packets from each terminal of buffering, total, in the path= from terminal to public Internet, assuming the connection to the public In= ternet is not a problem.=0A =0A ------=_20210709144001000000_34494 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Early measurements of = performance of Starlink have shown significant bufferbloat, as Dave Taht ha= s shown.

=0A

 

=0A

But..= .  Starlink is a moving target. The bufferbloat isn't a hardware issue= , it should be completely manageable, starting by simple firmware changes i= nside the Starlink system itself. For example, implementing fq_codel so tha= t bottleneck links just drop packets according to the Best Practices RFC,=0A

 

=0A

So I'm hoping t= his has improved since Dave's measurements. How much has it improved? What'= s the current maximum packet latency under full load,  Ive heard anecd= otally 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.

=0A

 

=0A

84 msec is not great - it's marginal for Zoom quality experien= ce (you want latencies significantly less than 100 msec. as a rule of thumb= for teleconferencing quality). But it is better than Dave's measurements s= howed.

=0A

 

=0A

Now Mus= k bragged that his network was "low latency" unlike other high speed servic= es, 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. 8= 4 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. Bu= t I regularly get 17 msec. between California and Massachusetts over the pu= blic Internet)

=0A

 

=0A

So 84 might be the current status. That would mean that someone at Srarlin= k might be paying some attention, but it is a long way from what Musk impli= ed.

=0A

 

=0A

 

= =0A

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 un= derlying delay of about 10 msec. to account for hops between source and des= tination. Lets say Starlink allocates 50 Mb/sec to each customer, packets a= re limited to 10,000 bits (1500 * 8), so the outbound queues should be limi= ted to about 0.01 * 50,000,000 / 10,000, which comes out to about 250 packe= ts from each terminal of buffering, total, in the path from terminal to pub= lic Internet, assuming the connection to the public Internet is not a probl= em.

=0A

 

=0A

 

= ------=_20210709144001000000_34494--