From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A9BF23CB37 for ; Sun, 18 Jul 2021 21:05:51 -0400 (EDT) Received: by mail-qk1-x731.google.com with SMTP id m3so15198065qkm.10 for ; Sun, 18 Jul 2021 18:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forwardingplane-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dsYINhrcE60Ky6nyvtE+mjOxuCApXF/CZvlLnZaQfhQ=; b=LXTLyHZ+gvXcKRn0Xr43It4VVi9nPgNIvlicg1u4g0xc6/YwAexZX9GkbyuS+4/4ZX syPavuQH6fCP4UrdeeDcR/FO5o+4Fs2HtECEShG9ZerMyPO7MyPhk+6Ods6cAEkelC0s iJx5B/a5ibbHmCGJ62vRtpFDJ9seAsfb85s1lvWVFCUV9vAuzgEaiqZa0QXlFyArl9Y2 CgfSyCaXnjCMQmuTLk7I6kWm4gHj+LJywKToiWYY+/OjEDz9+J8obXpBw4p4DQPkI+eN SgNJPU5nj6y4kchLO1PZqlEMTDx78vG0PqvGMWPB6o2fusrlQr0D5lFJ7J6QR/mXVzKH sqDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dsYINhrcE60Ky6nyvtE+mjOxuCApXF/CZvlLnZaQfhQ=; b=DzSxQjXffN3yf7Pi4NyDNbA9h8cpHKyHe4BudNlkACbtSipY5A5v0vFqz6DYe4LZVm xXp88LO1zEElBumjt+MCJ/gXofenhHlioArIgXK4fgZrvgYgVE1gbzuJzyrDx4Zbi/A9 T+rhv97GQq19eV1lQqcqY9Q2vMz3fml/kCBHjYWmkz2hrbA8OJ/LMx5Xk21y3GCH6qki QDa7SfOx7syqyXXdD3UslGi/Y9f8gVorZBOGhtY/1OLFOo8ymggVqy/f+X6GGzjlZHly HC45YD4V4+qwNJcfvNZvX7cEumJDSxciwnVlBaKHm3eYve44zXi9PzwEhaY0fuVnkIYL i6zQ== X-Gm-Message-State: AOAM533CDfe2SADJETJKWJsVHyBgGyRHhUJUKG0OxxUOPuLNrQlGlDN/ i7Igq/v9kKnZ70nW0cMkLDucZTAdarEs15K44Wwm2w== X-Google-Smtp-Source: ABdhPJxvFIq0bG6y1Vtf2rJeHv7+A9Qop4XF4mA5s2VC8io1J23mxyC+e/tg+5mLEf0H3vWREyT/yJIAqhbOXldZbGU= X-Received: by 2002:a05:620a:4441:: with SMTP id w1mr21984477qkp.272.1626656750766; Sun, 18 Jul 2021 18:05:50 -0700 (PDT) MIME-Version: 1.0 References: <1625856001.74681750@apps.rackspace.com> In-Reply-To: From: Nick Buraglio Date: Sun, 18 Jul 2021 20:05:39 -0500 Message-ID: To: Jonathan Bennett Cc: "David P. Reed" , Nathan Owens , starlink@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="000000000000cd256905c76f893f" 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: Mon, 19 Jul 2021 01:05:51 -0000 --000000000000cd256905c76f893f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We keep saying =E2=80=9Croute=E2=80=9D. What do we actually mean from a net= work stack perspective? Are we talking about relaying light / frames / electric or do we mean actual packet routing, because there are obviously a lot of important distinctions there. I=E2=80=99m willing to bet that there is no routing (as in layer 3 packet r= outing) at all except the Dish NAT all the way into their peering data center. The ground stations are very likely RF to fiber wave division back to a carrier hotel with no L3 buffering at all. That keeps latency very low (think O-E-O and E-O transitions) and moves L3 buffering to two locations and keeps the terrestrial network very easy to make redundant (optical protection, etc.). nb On Fri, Jul 16, 2021 at 12:39 PM Jonathan Bennett < jonathanbennett@hackaday.com> wrote: > > > On Fri, Jul 16, 2021, 12:35 PM Nathan Owens wrote: > >> The other case where they could provide benefit is very long distance >> paths --- NY to Tokyo, Johannesburg to London, etc... but presumably at >> high cost, as the capacity will likely be much lower than submarine cabl= es. >> >>> > Or traffic between Starlink customers. A video call between me and someon= e > else on the Starlink network is going to be drastically better if it can > route over the sats. > >> >>> On Fri, Jul 16, 2021 at 10:31 AM Mike Puchol wrote: >> >>> Satellite optical links are useful to extend coverage to areas where yo= u >>> don=E2=80=99t have gateways - thus, they will introduce additional late= ncy compared >>> to two space segment hops (terminal to satellite -> satellite to gatewa= y). >>> If you have terminal to satellite, two optical hops, then final satelli= te >>> to gateway, you will have more latency, not less. >>> >>> We are being =E2=80=9Csold=E2=80=9D optical links for what they are not= IMHO. >>> >>> Best, >>> >>> Mike >>> On Jul 16, 2021, 19:29 +0200, Nathan Owens , wrote: >>> >>> > As there are more satellites, the up down time will get closer to >>> 4-5ms rather then the ~7ms you list >>> >>> Possibly, if you do steering to always jump to the lowest latency >>> satellite. >>> >>> > with laser relays in orbit, and terminal to terminal routing in orbit= , >>> there is the potential for the theoretical minimum to tend lower >>> Maybe for certain users really in the middle of nowhere, but I did the >>> best-case math for "bent pipe" in Seattle area, which is as good as it = gets. >>> >>> On Fri, Jul 16, 2021 at 10:24 AM David Lang wrote: >>> >>>> hey, it's a good attitude to have :-) >>>> >>>> Elon tends to set 'impossible' goals, miss the timeline a bit, and com= e >>>> very >>>> close to the goal, if not exceed it. >>>> >>>> As there are more staellites, the up down time will get closer to 4-5m= s >>>> rather >>>> then the ~7ms you list, and with laser relays in orbit, and terminal t= o >>>> terminal >>>> routing in orbit, there is the potential for the theoretical minimum t= o >>>> tend >>>> lower, giving some headroom for other overhead but still being in the >>>> 20ms >>>> range. >>>> >>>> David Lang >>>> >>>> On Fri, 16 Jul 2021, Nathan Owens wrote: >>>> >>>> > Elon said "foolish packet routing" for things over 20ms! Which seems >>>> crazy >>>> > if you do some basic math: >>>> > >>>> > - Sat to User Terminal distance: 550-950km air/vacuum: 1.9 - 3.3ms >>>> > - Sat to GW distance: 550-950km air/vacuum: 1.9 - 3.3ms >>>> > - GW to PoP Distance: 50-800km fiber: 0.25 - 4ms >>>> > - PoP to Internet Distance: 50km fiber: 0.25 - 0.5ms >>>> > - Total one-way delay: 4.3 - 11.1ms >>>> > - Theoretical minimum RTT: 8.6ms - 22.2ms, call it 15.4ms >>>> > >>>> > This includes no transmission delay, queuing delay, >>>> > processing/fragmentation/reassembly/etc, and no time-division >>>> multiplexing. >>>> > >>>> > On Fri, Jul 16, 2021 at 10:09 AM David Lang wrote: >>>> > >>>> >> I think it depends on if you are looking at datacenter-to-datacente= r >>>> >> latency of >>>> >> home to remote datacenter latency :-) >>>> >> >>>> >> my rule of thumb for cross US ping time has been 80-100ms latency >>>> (but >>>> >> it's been >>>> >> a few years since I tested it). >>>> >> >>>> >> I note that an article I saw today said that Elon is saying that >>>> latency >>>> >> will >>>> >> improve significantly in the near future, that up/down latency is >>>> ~20ms >>>> >> and the >>>> >> additional delays pushing it to the 80ms range are 'stupid packet >>>> routing' >>>> >> problems that they are working on. >>>> >> >>>> >> If they are still in that level of optimization, it doesn't surpris= e >>>> me >>>> >> that >>>> >> they haven't really focused on the bufferbloat issue, they have mor= e >>>> >> obvious >>>> >> stuff to fix first. >>>> >> >>>> >> David Lang >>>> >> >>>> >> >>>> >> On Fri, 16 Jul 2021, Wheelock, Ian wrote: >>>> >> >>>> >>> Date: Fri, 16 Jul 2021 10:21:52 +0000 >>>> >>> From: "Wheelock, Ian" >>>> >>> To: David Lang , David P. Reed >>>> >>> Cc: "starlink@lists.bufferbloat.net" < >>>> starlink@lists.bufferbloat.net> >>>> >>> Subject: Re: [Starlink] Starlink and bufferbloat status? >>>> >>> >>>> >>> Hi David >>>> >>> In terms of the Latency that David (Reed) mentioned for California >>>> to >>>> >> Massachusetts of about 17ms over the public internet, it seems a bi= t >>>> faster >>>> >> than what I would expect. My own traceroute via my VDSL link shows >>>> 14ms >>>> >> just to get out of the operator network. >>>> >>> >>>> >>> https://www.wondernetwork.com is a handy tool for checking >>>> geographic >>>> >> ping perf between cities, and it shows a min of about 66ms for ping= s >>>> >> between Boston and San Diego >>>> >> https://wondernetwork.com/pings/boston/San%20Diego (so about 33ms >>>> for >>>> >> 1-way transfer). >>>> >>> >>>> >>> 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 i= s >>>> just >>>> >> over 20ms. If the network equipment between the Boston and San Dieg= o >>>> is >>>> >> factored in, with some buffering along the way, 33ms does seem quit= e >>>> >> reasonable over the 20ms for speed of light in fibre for that 1-way >>>> transfer >>>> >>> >>>> >>> -Ian Wheelock >>>> >>> >>>> >>> From: Starlink on behalf >>>> of >>>> >> David Lang >>>> >>> Date: Friday 9 July 2021 at 23:59 >>>> >>> To: "David P. Reed" >>>> >>> Cc: "starlink@lists.bufferbloat.net" < >>>> starlink@lists.bufferbloat.net> >>>> >>> Subject: Re: [Starlink] Starlink and bufferbloat status? >>>> >>> >>>> >>> IIRC, the definition of 'low latency' for the FCC was something li= ke >>>> >> 100ms, and Musk was predicting <40ms. roughly competitive with >>>> landlines, >>>> >> and worlds better than geostationary satellite (and many >>>> >>> External (mailto:david@lang.hm) >>>> >>> >>>> >> >>>> https://shared.outlook.inky.com/report?id=3DY29tbXNjb3BlL2lhbi53aGVlbG= 9ja0Bjb21tc2NvcGUuY29tL2I1MzFjZDA4OTZmMWI0Yzc5NzdiOTIzNmY3MTAzM2MxLzE2MjU4N= zE1NDkuNjU=3D#key=3D19e8545676e28e577c813de83a4cf1dc >>>> >> https://www.inky.com/banner-faq/ https://www.inky.com >>>> >>> >>>> >>> IIRC, the definition of 'low latency' for the FCC was something li= ke >>>> >> 100ms, and >>>> >>> Musk was predicting <40ms. >>>> >>> >>>> >>> roughly competitive with landlines, and worlds better than >>>> geostationary >>>> >>> satellite (and many wireless ISPs) >>>> >>> >>>> >>> but when doing any serious testing of latency, you need to be wire= d >>>> to >>>> >> the >>>> >>> router, wifi introduces so much variability that it swamps the >>>> signal. >>>> >>> >>>> >>> David Lang >>>> >>> >>>> >>> On Fri, 9 Jul 2021, David P. Reed wrote: >>>> >>> >>>> >>>> Date: Fri, 9 Jul 2021 14:40:01 -0400 (EDT) >>>> >>>> From: David P. Reed >>>> >>>> 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, implementin= g >>>> >> fq_codel so that bottleneck links just drop packets according to th= e >>>> 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 measurement= s >>>> 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 termina= l >>>> >> through the satellite. 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 a= t >>>> >> 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. >>>> >>> _______________________________________________ >>>> >>> Starlink mailing list >>>> >>> Starlink@lists.bufferbloat.net >>>> >>> >>>> >> >>>> https://secure-web.cisco.com/1sNc_-1HhGCW7xdirt_lAoAy5Nn5T6UA85Scjn5BR= 7QHXtumhrf6RKn78SuRJG7DUKI3duggU9g6hJKW-Ze07HTczYqB9mBpIeALqk5drQ7nMvM8K7Jb= WfUbPR7JSNrI75UjiNXQk0wslBfoOTvkMlRj5eMOZhps7DMGBRQTVAeTd5vwXoQtDgS6zLCcJkr= cO2S9MRSCC4f1I17SzgQJIwqo3LEwuN6lD-pkX0MFLqGr2zzsHw5eapd-VBlHu5reC4-OEn2zHk= b7HNzS1pcueF6tsUE1vFRsWs2SIOwU5MvbKe3J3Q6NRQ40cHI1AGd-i/https://lists.buffe= rbloat.net/listinfo/starlink >>>> >>> >>>> >>> _______________________________________________ >>>> >> Starlink mailing list >>>> >> Starlink@lists.bufferbloat.net >>>> >> https://lists.bufferbloat.net/listinfo/starlink >>>> >> >>>> > >>>> >>> _______________________________________________ >>> Starlink mailing list >>> Starlink@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/starlink >>> >>> _______________________________________________ >> Starlink mailing list >> Starlink@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/starlink >> > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink > --000000000000cd256905c76f893f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We keep saying =E2=80=9Croute=E2=80=9D. What do we actual= ly mean from a network stack perspective? Are we talking about relaying lig= ht / frames / electric or do we mean actual packet routing, because there a= re obviously a lot of important distinctions there.=C2=A0
I=E2=80=99m willing to bet that there is no routing (as in layer 3 pa= cket routing) at all except the Dish NAT all the way into their peering dat= a center. The ground stations are very likely RF to fiber wave division bac= k to a carrier hotel with no L3 buffering at all. That keeps latency very l= ow (think O-E-O and E-O=C2=A0transitions) and moves L3 buffering to two=C2=A0locations and keeps the terrestri= al network very easy to make redundant (optical protection, etc.).

nb

On Fri, Jul 16, 2021 at 1= 2:39 PM Jonathan Bennett <jonathanbennett@hackaday.com> wrote:


On Fri, Jul 16, 2021, 12:35 PM Nathan Owens <nathan@nathan.io> wro= te:
The other case where they co= uld provide benefit is very long distance paths --- NY to Tokyo, Johannesbu= rg to London, etc... but presumably at high cost, as the capacity will like= ly be much lower than submarine cables.

= Or traffic between Starlink customers. A video call between me and someone = else on the Starlink network is going to be drastically better if it can ro= ute over the sats.

On Fri, Jul 16,= 2021 at 10:31 AM Mike Puchol <mike@starlink.sx> wrote:
=
Satellite optical links are useful to extend coverage to = areas where you don=E2=80=99t have gateways - thus, they will introduce add= itional latency compared to two space segment hops (terminal to satellite -= > satellite to gateway). If you have terminal to satellite, two optical = hops, then final satellite to gateway, you will have more latency, not less= .

We are being =E2=80=9Csold=E2=80=9D optical links for what they are not IMH= O.

Best,

Mike
On Jul 16, 2021, 19:29 +0200, Nathan Owen= s <nathan@nathan.io>, wrote:
> As there are more satellites, the up down time will g= et closer to 4-5ms rather then the ~7ms you list

Possibly, if you do steering to always jump to the lowest latency sate= llite.=C2=A0

> with laser relays in orbit, and terminal to terminal routing in o= rbit, there is the potential for the theoretical minimum to tend lower
<= /div>
Maybe for certain users really in the middle of nowhere, but I did the= best-case math for "bent pipe" in Seattle area, which is as good= as it gets.

On Fri, Jul 16, 2021 at 10:24 AM Davi= d Lang <david@lang.hm> wrote:
hey, it's a good attitude to have :-)

Elon tends to set 'impossible' goals, miss the timeline a bit, and = come very
close to the goal, if not exceed it.

As there are more staellites, the up down time will get closer to 4-5ms rat= her
then the ~7ms you list, and with laser relays in orbit, and terminal to ter= minal
routing in orbit, there is the potential for the theoretical minimum to ten= d
lower, giving some headroom for other overhead but still being in the 20ms<= br> range.

David Lang

=C2=A0 On Fri, 16 Jul 2021, Nathan Owens wrote:

> Elon said "foolish packet routing" for things over 20ms! Whi= ch seems crazy
> if you do some basic math:
>
>=C2=A0 =C2=A0- Sat to User Terminal distance: 550-950km air/vacuum: 1.9= - 3.3ms
>=C2=A0 =C2=A0- Sat to GW distance: 550-950km air/vacuum: 1.9 - 3.3ms >=C2=A0 =C2=A0- GW to PoP Distance: 50-800km fiber: 0.25 - 4ms
>=C2=A0 =C2=A0- PoP to Internet Distance: 50km fiber: 0.25 - 0.5ms
>=C2=A0 =C2=A0- Total one-way delay: 4.3 - 11.1ms
>=C2=A0 =C2=A0- Theoretical minimum RTT: 8.6ms - 22.2ms, call it 15.4ms<= br> >
> This includes no transmission delay, queuing delay,
> processing/fragmentation/reassembly/etc, and no time-division multiple= xing.
>
> On Fri, Jul 16, 2021 at 10:09 AM David Lang <david@lang.hm> wrote= :
>
>> I think it depends on if you are looking at datacenter-to-datacent= er
>> latency of
>> home to remote datacenter latency :-)
>>
>> my rule of thumb for cross US ping time has been 80-100ms latency = (but
>> it's been
>> a few years since I tested it).
>>
>> I note that an article I saw today said that Elon is saying that l= atency
>> will
>> improve significantly in the near future, that up/down latency is = ~20ms
>> and the
>> additional delays pushing it to the 80ms range are 'stupid pac= ket routing'
>> problems that they are working on.
>>
>> If they are still in that level of optimization, it doesn't su= rprise me
>> that
>> they haven't really focused on the bufferbloat issue, they hav= e more
>> obvious
>> stuff to fix first.
>>
>> David Lang
>>
>>
>>=C2=A0 =C2=A0On Fri, 16 Jul 2021, Wheelock, Ian wrote:
>>
>>> Date: Fri, 16 Jul 2021 10:21:52 +0000
>>> From: "Wheelock, Ian" <ian.wheelock@comms= cope.com>
>>> To: David Lang <david@lang.hm>, David P. Reed <dpreed= @deepplum.com>
>>> Cc: "starlink@lists.bufferbloat.net"= <starlink@lists.bufferbloat.net>
>>> Subject: Re: [Starlink] Starlink and bufferbloat status?
>>>
>>> Hi David
>>> In terms of the Latency that David (Reed) mentioned for Califo= rnia to
>> Massachusetts of about 17ms over the public internet, it seems a b= it faster
>> than what I would expect. My own traceroute via my VDSL link shows= 14ms
>> just to get out of the operator network.
>>>
>>> https://www.wondernetwork.com=C2=A0 is a ha= ndy tool for checking geographic
>> ping perf between cities, and it shows a min of about 66ms for pin= gs
>> between Boston and San Diego
>> https://wondernetwork.com/ping= s/boston/San%20Diego (so about 33ms for
>> 1-way transfer).
>>>
>>> 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 Die= go is
>> factored in, with some buffering along the way, 33ms does seem qui= te
>> reasonable over the 20ms for speed of light in fibre for that 1-wa= y transfer
>>>
>>> -Ian Wheelock
>>>
>>> From: Starlink <starlink-bounces@lists.= bufferbloat.net> on behalf of
>> David Lang <david@lang.hm>
>>> Date: Friday 9 July 2021 at 23:59
>>> To: "David P. Reed" <dpreed@deepplum.com>=
>>> Cc: "starlink@lists.bufferbloat.net"= <starlink@lists.bufferbloat.net>
>>> Subject: Re: [Starlink] Starlink and bufferbloat status?
>>>
>>> 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
>>> External (mailto:david@lang.hm)
>>>
>> https://shared.outlook.inky.com/r= eport?id=3DY29tbXNjb3BlL2lhbi53aGVlbG9ja0Bjb21tc2NvcGUuY29tL2I1MzFjZDA4OTZm= MWI0Yzc5NzdiOTIzNmY3MTAzM2MxLzE2MjU4NzE1NDkuNjU=3D#key=3D19e8545676e28e577c= 813de83a4cf1dc
>>=C2=A0 https://www.inky.com/banner-faq/=C2=A0= https://www.inky.com
>>>
>>> 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 geo= stationary
>>> satellite (and many wireless ISPs)
>>>
>>> but when doing any serious testing of latency, you need to be = wired to
>> the
>>> router, wifi introduces so much variability that it swamps the= signal.
>>>
>>> David Lang
>>>
>>> On Fri, 9 Jul 2021, David P. Reed wrote:
>>>
>>>> Date: Fri, 9 Jul 2021 14:40:01 -0400 (EDT)
>>>> From: David P. Reed <dpreed@deepplum.com>
>>>> To: starlink@lists.bufferbloat.net
>>>> Subject: [Starlink] Starlink and bufferbloat status?
>>>>
>>>>
>>>> Early measurements of performance of Starlink have shown s= ignificant
>> bufferbloat, as Dave Taht has shown.
>>>>
>>>> But...=C2=A0 Starlink is a moving target. The bufferbloat = isn't a hardware
>> issue, it should be completely manageable, starting by simple firm= ware
>> changes inside the Starlink system itself. For example, implementi= ng
>> fq_codel so that bottleneck links just drop packets according to t= he Best
>> Practices RFC,
>>>>
>>>> So I'm hoping this has improved since Dave's measu= rements. How much has
>> it improved? What's the current maximum packet latency under f= ull
>> load,=C2=A0 Ive heard anecdotally that a friend of a friend gets 8= 4 msec. *ping
>> times under full load*, but he wasn't using flent or some othe= r 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 thum= b for
>> teleconferencing quality). But it is better than Dave's measur= ements showed.
>>>>
>>>> Now Musk bragged that his network was "low latency&qu= ot; unlike other high
>> speed services, which means low end-to-end latency.=C2=A0 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 termin= al
>> through the satellite. But I regularly get 17 msec. between Califo= rnia and
>> Massachusetts over the public Internet)
>>>>
>>>> So 84 might be the current status. That would mean that so= meone 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 pack= ets queued on
>> an egress link should be chosen by taking the hardware bottleneck<= br> >> throughput of any path, combined with an end-to-end Internet under= lying
>> 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 ar= e limited
>> to 10,000 bits (1500 * 8), so the outbound queues should be limite= d to
>> about 0.01 * 50,000,000 / 10,000, which comes out to about 250 pac= kets from
>> each terminal of buffering, total, in the path from terminal to pu= blic
>> Internet, assuming the connection to the public Internet is not a = problem.
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>>
>> https://secure-web.cisco.com/1sNc_-1HhGCW7xdirt_lAoAy5Nn5= T6UA85Scjn5BR7QHXtumhrf6RKn78SuRJG7DUKI3duggU9g6hJKW-Ze07HTczYqB9mBpIeALqk5= drQ7nMvM8K7JbWfUbPR7JSNrI75UjiNXQk0wslBfoOTvkMlRj5eMOZhps7DMGBRQTVAeTd5vwXo= QtDgS6zLCcJkrcO2S9MRSCC4f1I17SzgQJIwqo3LEwuN6lD-pkX0MFLqGr2zzsHw5eapd-VBlHu= 5reC4-OEn2zHkb7HNzS1pcueF6tsUE1vFRsWs2SIOwU5MvbKe3J3Q6NRQ40cHI1AGd-i/https:= //lists.bufferbloat.net/listinfo/starlink
>>>
>>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/lis= tinfo/starlink
>>
>
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/sta= rlink
_______________________________________________
Starlink mailing list
Starlin= k@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
--000000000000cd256905c76f893f--