From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bosmailout09.eigbox.net (bosmailout09.eigbox.net [66.96.189.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B14CD3B2A4 for ; Fri, 9 Jul 2021 16:08:30 -0400 (EDT) Received: from bosmailscan06.eigbox.net ([10.20.15.6]) by bosmailout09.eigbox.net with esmtp (Exim) id 1m1wnW-0006iL-1r for starlink@lists.bufferbloat.net; Fri, 09 Jul 2021 16:08:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alum.mit.edu; s=dkim; h=Sender:Content-Type:MIME-Version:Message-ID:Date: Subject:In-Reply-To:References:To:From:Reply-To:Cc:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=bdB/1xU5p5quy+LqddI0bwMiRR0iox9hb0OGeYjmOYY=; b=aDCoCuuGIhGfVMSkU6qTCaPFYK eMPJBJPQYAJtdFVQ4ULMtI0hnWG+jQjmkHQtm0FlODHcnnhcl+nSCMQvfPce0rhhX1QFo5yyEthm4 an9lS+SBXyeX6xFbkBkmDyRx/58HvjsZjtcGGzV1byH5q8Z/HDZxqvRUwEdeTck3RFPhEJNY8CtL3 Aq6JeAp7lrjrBf+UUXM0BuPCrwil7wLfzoL65vPd3lGOcP8g5D3yOacvzvWck5whc0vx9TlWUPJAF AZ0tGVcMyKz0/nChs2dZiWK55Uk/xxeE9+haoBDie7SoCaXH3JNLTCkrX3fEw4PNvXfNNLTku+KC/ t8F5cp9g==; Received: from [10.115.3.32] (helo=bosimpout12) by bosmailscan06.eigbox.net with esmtp (Exim) id 1m1wnV-0002KJ-P4 for starlink@lists.bufferbloat.net; Fri, 09 Jul 2021 16:08:29 -0400 Received: from bosauthsmtp09.yourhostingaccount.com ([10.20.18.9]) by bosimpout12 with id T88S250080BkY8i0188VtT; Fri, 09 Jul 2021 16:08:29 -0400 X-Authority-Analysis: v=2.3 cv=d4VuNSrE c=1 sm=1 tr=0 a=+tcVrJynzLVJ9yqDAOBWjQ==:117 a=x+7tlP9+fMpTIVJEmcsKvw==:17 a=e_q4qTt1xDgA:10 a=Wo7qeYC63mUA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=kurRqvosAAAA:8 a=odw5To6gQJvCnPNJzMkA:9 a=CjuIK1q_8ugA:10 a=SSmOFEACAAAA:8 a=IWtXM0uFrT7Ey7WVJ5gA:9 a=ZUVli10jmaeNlPxG:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=kbxRQ_lfPIoQnHsAj2-A:22 Received: from c-73-222-32-85.hsd1.ca.comcast.net ([73.222.32.85]:57193 helo=SRA6) by bosauthsmtp09.eigbox.net with esmtpa (Exim) id 1m1wnS-0003yW-4y; Fri, 09 Jul 2021 16:08:26 -0400 Reply-To: From: "Dick Roy" To: "'David P. Reed'" , References: <1625856001.74681750@apps.rackspace.com> In-Reply-To: <1625856001.74681750@apps.rackspace.com> Date: Fri, 9 Jul 2021 13:08:22 -0700 Organization: SRA Message-ID: <8DE3A819BD7C43F9A168399D53FC48B3@SRA6> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0FD6_01D774C3.810D3490" X-Mailer: Microsoft Office Outlook 11 Thread-Index: Add08ddftUU4eZmSTeWiENFQS3I1gQAC+c0Q X-MimeOLE: Produced By Microsoft MimeOLE X-EN-UserInfo: f809475445fb8041985048e338e1a001:931c98230c6409dcc37fa7e93b490c27 X-EN-AuthUser: dickroy@intellicommunications.com Sender: "Dick Roy" X-EN-OrigIP: 73.222.32.85 X-EN-OrigHost: c-73-222-32-85.hsd1.ca.comcast.net Subject: Re: [Starlink] Starlink and bufferbloat status? 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 20:08:30 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0FD6_01D774C3.810D3490 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit _____ 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 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. ------=_NextPart_000_0FD6_01D774C3.810D3490 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

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 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.

 

 

------=_NextPart_000_0FD6_01D774C3.810D3490--