From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (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 A95573B29D for ; Thu, 14 Jul 2022 11:32:29 -0400 (EDT) Received: by mail-ua1-x932.google.com with SMTP id c7so776933uak.1 for ; Thu, 14 Jul 2022 08:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nathan.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Txoqae96w3R/MBTitXO1WknEe3Mnlz737aj8aEuv5u4=; b=qGoTqQVfQoFahwgdOmd967Z7ijsy5N88pRfIPpostv6/ZhXI8t6giYAf4T73n/tPe+ 4iQEwPDZ2/mfURRWHSHctpnlCieoABHqRvGYI0vGXZv+JxP2QZ+eCVtWIIpd0g5hUvF9 8IphwWdXQubFb1NxAzU65gaKcJQ6RWfQxozCkt8m5KfvfsoLD168fccVWuabHmd9vGVQ l558Q/6hMO5WU9cQx+04cnyOGxrIhBQucWsumM2HtH6uxiAfF67reptFAK0D1xA/WV1I V1iF+cMlsYDCpCd4AwSTKhfXUhSQEXNbFaQH/ptV1W+tMBuHJNyoPIf6K3IhHygdwa21 qA5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Txoqae96w3R/MBTitXO1WknEe3Mnlz737aj8aEuv5u4=; b=Mnrg1zoANY7PdFpB/NcHael6+H4Y8GptseXKyhMGHvwXdeC+p+iKnudqWQq9HJI9ln CuMl1nM2eZgaar0a7S3Q3RdEVzScndd7lVKO70pU5gnC8HKv2ilXarR4pp+sgZmS1N/l a7iWL3/XKLmE7VJUyR7aH4zuxkhXVpwUggmTA0SzQ7X1qTMa/fUOJKd8vf9u1Xt9U7ho 2LINGxC2ck6iRBDBX/yRAwT8AlqwyZKplevZS5Jr4PWVkwlTJtnVlmccKuv7n99e51x1 j2wpB/SyR2F2byqpQ60LnXjn46HIKA4WLAde6GbNWZpnkiPx1miPrNTg6OXekPOWcEho gxTA== X-Gm-Message-State: AJIora/ie5V7uH+zRyg9wcL/Ieu+mQZKDaOXU6d4si/SY2cYq/RbLp5P AOuFjvkLxg6tSe6aC49jsCZgQLm0+0sNn1AGDYD69g== X-Google-Smtp-Source: AGRyM1uNdDomYEvwZ/7Se0SM5UVePASc33R/5tbGhmpUp2EAudfygY3il6Yf12Wqo7iQl7Wg2O7hBDfgmNp07biEeYw= X-Received: by 2002:ab0:2759:0:b0:382:d426:4138 with SMTP id c25-20020ab02759000000b00382d4264138mr3656411uap.84.1657812748890; Thu, 14 Jul 2022 08:32:28 -0700 (PDT) MIME-Version: 1.0 References: <20220713173602.0582c9b3@spidey.rellim.com> <92n4s129-6r15-7q75-7293-qpo73q298srn@ynat.uz> <841ca6dc-d6d3-46ab-87c0-d6bcaa31533b@Spark> <42D3F3C5-C1B3-48EA-8C45-2540ACD787E4@gmx.de> <0C0F0D5F-7CF6-412A-AD1A-392323ADB2FB@gmx.de> <858AB3A2-EDE0-4035-A4FE-EC2313CC3197@puck.nether.net> <0e33c411-d5a7-411f-a80b-ae9d48cdaf2a@Spark> <5CEB3DFB-D47D-45A4-90E8-898842DA104A@gmx.de> In-Reply-To: <5CEB3DFB-D47D-45A4-90E8-898842DA104A@gmx.de> From: Nathan Owens Date: Thu, 14 Jul 2022 08:32:18 -0700 Message-ID: To: Sebastian Moeller Cc: Mike Puchol , Mike Puchol via Starlink , Jared Mauch , Nitinder Mohan Content-Type: multipart/alternative; boundary="0000000000000086a805e3c59ce9" Subject: Re: [Starlink] starlink at sea 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: Thu, 14 Jul 2022 15:32:29 -0000 --0000000000000086a805e3c59ce9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Based on my irtt data, handover seems to be a low number of milliseconds, perhaps 50ms at most. They do tend to switch sats every 15 seconds, based on the data I collected when the gRPC api was still around. Not sure what the 4 second interval is. On Thu, Jul 14, 2022 at 8:28 AM Sebastian Moeller via Starlink < starlink@lists.bufferbloat.net> wrote: > Hi Mike, > > On 14 July 2022 16:56:21 CEST, Mike Puchol via Starlink < > starlink@lists.bufferbloat.net> wrote: > >The handovers are clear from the RF traces, > > Can you estimate how long a handover takes? And are these linked > somehow to either the 4second or 15second intervals visible in starlink > latency traces? > > > Regards > Sebastian > > > but they won=E2=80=99t indicate per se what satellite is being used. I ha= ve a > cunning plan for a rotating vertical metal plate which, given the right > calculations, would block 10=C2=B0 of the FOV, which would allow inferenc= e of > the satellite in use. There are also narrowband uplink signals that are > likely used for channel sounding and basic signaling between terminal and > satellite. > > > >The other interesting observation is that the power spike (~200W for 1-2 > seconds) that happens at boot time, corresponds to a burst of these > narrowband transmissions on various frequencies at once. > > > >Best, > > > >Mike > >On Jul 14, 2022, 15:33 +0200, Nitinder Mohan , wrote: > >> Hi Jared, > >> > >> Turns out that SpaceX has deprecated the API calls to get satelliteID > and cellID over gRPC so that information is no longer available. See > https://github.com/danopstech/starlink/issues/27 > >> > >> Too bad since those would have been quite useful to understand > performance trends. > >> > >> Thanks and Regards > >> > >> Nitinder Mohan > >> Technical University Munich (TUM) > >> https://www.nitindermohan.com/ > >> > >> From: Nitinder Mohan > >> Reply: Nitinder Mohan > >> Date: 14. July 2022 at 15:05:42 > >> To: Jared Mauch > >> Cc: Dave Taht via Starlink , Mike > Puchol > >> Subject: Re: [Starlink] starlink at sea > >> > >> > Hi Jared, > >> > > >> > Thanks much for the pointer. This seems promising! > >> > > >> > We have a stationary dish available locally so we can try pulling > information at our end. > >> > > >> > Thanks and Regards > >> > > >> > Nitinder Mohan > >> > Technical University Munich (TUM) > >> > https://www.nitindermohan.com/ > >> > > >> > From: Jared Mauch > >> > Reply: Jared Mauch > >> > Date: 14. July 2022 at 14:57:25 > >> > To: Nitinder Mohan > >> > Cc: Mike Puchol , Dave Taht via Starlink < > starlink@lists.bufferbloat.net> > >> > Subject: Re: [Starlink] starlink at sea > >> > > >> > > I haven=E2=80=99t poked hard, but it does seem you can get it: > >> > > > >> > > currentCellId current_cell_id > >> > > > >> > > Seem to be in the GRPC proto dump from the dish. > >> > > > >> > > > https://github.com/sparky8512/starlink-grpc-tools/blob/main/extract_proto= set.py > >> > > > >> > > This should pull it out, if you want from my (stationary) dish I > bet I can run something to pull/dump the info. > >> > > > >> > > - jared > >> > > > >> > > > On Jul 14, 2022, at 8:49 AM, Nitinder Mohan via Starlink < > starlink@lists.bufferbloat.net> wrote: > >> > > > > >> > > > Hi Mike, > >> > > > > >> > > > Do you happen to have a tool that can extract the current uplink > channel of Starlink and (more importantly) which staellite it is connecte= d > to at any given time? I wanted to track the handovers in Starlink and try > to find its impact on network performance but cannot seem to get those > values. > >> > > > > >> > > > Thanks and Regards > >> > > > > >> > > > Nitinder Mohan > >> > > > Technical University Munich (TUM) > >> > > > https://www.nitindermohan.com/ > >> > > > > >> > > > From: Sebastian Moeller via Starlink < > starlink@lists.bufferbloat.net> > >> > > > Reply: Sebastian Moeller > >> > > > Date: 14. July 2022 at 14:35:16 > >> > > > To: Mike Puchol > >> > > > Cc: Dave Taht via Starlink > >> > > > Subject: Re: [Starlink] starlink at sea > >> > > > > >> > > >> Hi Mike. > >> > > >> > >> > > >> Thanks a lot. This is intersting. > >> > > >> > >> > > >> > On Jul 14, 2022, at 14:02, Mike Puchol > wrote: > >> > > >> > > >> > > >> > The uplink is an OFDM signal with 128 subcarriers, looking at > the signal in the time domain reveals a frame length corresponding to 14% > (from memory, 1,1 us frame vs 6.7 us pause). I have two terminals 1 meter > apart and they can each achieve 30 Mbps at the same time over the same > uplink channel. I would expect the satellite to assign a particular set o= f > slots to a terminal. > >> > > >> > >> > > >> So assuming the 30 Mbps being gross rate and not measured > goodput: > >> > > >> > >> > > >> 30Mbps -> 30 / (1.1/(6.7+1.1)) =3D 212.73 Mb/s while actively > sending, and > >> > > >> 1000000=C2=B5s/s / (6.7+1.1)=C2=B5s =3D 128205.128205 slots/sec > >> > > >> (30 / (1.1/(6.7+1.1))) * 1000^2 / (1000000 / (6.7+1.1)) =3D > 1659.27 bits/slot 1659.27/8 =3D 207.41 Bytes/slot > >> > > >> > >> > > >> with 128 subcarriers that would be approximately an average > >> > > >> > >> > > >> 1659.27/128 =3D 12.96 or ~ 13 bit/subcarrier > >> > > >> > >> > > >> if all carriers are loaded equally (which is unlikely, I expect > some re-arrangement ot bits between subcarriers to account for different > levels of noise and what not). > >> > > >> > >> > > >> > >> > > >> > If there are any OFDM blind analysis experts in the room, > shout! > >> > > >> > >> > > >> Please do! > >> > > >> Regards > >> > > >> Sebastian > >> > > >> > >> > > >> > > >> > > >> > Best, > >> > > >> > > >> > > >> > Mike > >> > > >> > On Jul 14, 2022, 13:33 +0200, Sebastian Moeller < > moeller0@gmx.de>, wrote: > >> > > >> >> Hi Mike, > >> > > >> >> > >> > > >> >>> On Jul 14, 2022, at 13:15, Mike Puchol via Starlink < > starlink@lists.bufferbloat.net> wrote: > >> > > >> >>> > >> > > >> >>> On the multiple terminals, I have verified that the duty > cycle of a consumer terminal is 14%, thus, you could have 7 terminals on = a > single uplink channel with some guard time. > >> > > >> >> > >> > > >> >> Could you elaborate how that works.how the terminals will be > interleaved in that situation? > >> > > >> >> > >> > > >> >> Regards > >> > > >> >> Sebastian > >> > > >> >> > >> > > >> >> > >> > > >> >>> I have seen 30 Mbps up, so you=E2=80=99d be able to push 21= 0 Mbps in > uplink, or a spectral efficiency of about 3.4 bps/Hz. > >> > > >> >> > >> > > >> > >> > > >> _______________________________________________ > >> > > >> 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 > >> > > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink > --0000000000000086a805e3c59ce9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Based on my irtt data, handover seems to be a low number o= f milliseconds, perhaps 50ms at most. They do tend to switch sats every 15 = seconds, based on the data I collected when the gRPC api was still around. = Not sure what the 4 second interval is.

On Thu, Jul 14, 2022 at 8:28 AM= Sebastian Moeller via Starlink <starlink@lists.bufferbloat.net> wrote:
Hi Mike,

On 14 July 2022 16:56:21 CEST, Mike Puchol via Starlink <starlink@lists.bufferb= loat.net> wrote:
>The handovers are clear from the RF traces,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Can you estimate how long a handover take= s? And are these linked somehow to either the 4second or 15second intervals= visible in starlink latency traces?


Regards
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sebastian


but they won=E2=80=99t indicate per se what satellite is being used. I have= a cunning plan for a rotating vertical metal plate which, given the right = calculations, would block 10=C2=B0 of the FOV, which would allow inference = of the satellite in use. There are also narrowband uplink signals that are = likely used for channel sounding and basic signaling between terminal and s= atellite.
>
>The other interesting observation is that the power spike (~200W for 1-= 2 seconds) that happens at boot time, corresponds to a burst of these narro= wband transmissions on various frequencies at once.
>
>Best,
>
>Mike
>On Jul 14, 2022, 15:33 +0200, Nitinder Mohan <mohan@in.tum.de>, wrote:
>> Hi Jared,
>>
>> Turns out that SpaceX has deprecated the API calls to get satellit= eID and cellID over gRPC so that information is no longer available. See=C2= =A0https://github.com/danopstech/starlink/issues/27<= /a>
>>
>> Too bad since those would have been quite useful to understand per= formance trends.
>>
>> Thanks and Regards
>>
>> Nitinder Mohan
>> Technical University Munich (TUM)
>> https://www.nitindermohan.com/
>>
>> From:=C2=A0Nitinder Mohan <mohan@in.tum.de>
>> Reply:=C2=A0Nitinder Mohan <mohan@in.tum.de>
>> Date:=C2=A014. July 2022 at 15:05:42
>> To:=C2=A0Jared Mauch <jared@puck.nether.net>
>> Cc:=C2=A0Dave Taht via Starlink <starlink@lists.bufferbloat.net>= ;, Mike Puchol <mi= ke@starlink.sx>
>> Subject:=C2=A0 Re: [Starlink] starlink at sea
>>
>> > Hi Jared,
>> >
>> > Thanks much for the pointer. This seems promising!
>> >
>> > We have a stationary dish available locally so we can try pul= ling information at our end.
>> >
>> > Thanks and Regards
>> >
>> > Nitinder Mohan
>> > Technical University Munich (TUM)
>> > https://www.nitindermohan.com/
>> >
>> > From:=C2=A0Jared Mauch <jared@puck.nether.net>
>> > Reply:=C2=A0Jared Mauch <jared@puck.nether.net>
>> > Date:=C2=A014. July 2022 at 14:57:25
>> > To:=C2=A0Nitinder Mohan <mohan@in.tum.de>
>> > Cc:=C2=A0Mike Puchol <mike@starlink.sx>, Dave Taht via Starlink <starlink@li= sts.bufferbloat.net>
>> > Subject:=C2=A0 Re: [Starlink] starlink at sea
>> >
>> > > I haven=E2=80=99t poked hard, but it does seem you can g= et it:
>> > >
>> > > currentCellId current_cell_id
>> > >
>> > > Seem to be in the GRPC proto dump from the dish.
>> > >
>> > > ht= tps://github.com/sparky8512/starlink-grpc-tools/blob/main/extract_protoset.= py
>> > >
>> > > This should pull it out, if you want from my (stationary= ) dish I bet I can run something to pull/dump the info.
>> > >
>> > > - jared
>> > >
>> > > > On Jul 14, 2022, at 8:49 AM, Nitinder Mohan via Sta= rlink <starlink@lists.bufferbloat.net> wrote:
>> > > >
>> > > > Hi Mike,
>> > > >
>> > > > Do you happen to have a tool that can extract the c= urrent uplink channel of Starlink and (more importantly) which staellite it= is connected to at any given time? I wanted to track the handovers in Star= link and try to find its impact on network performance but cannot seem to g= et those values.
>> > > >
>> > > > Thanks and Regards
>> > > >
>> > > > Nitinder Mohan
>> > > > Technical University Munich (TUM)
>> > > > https://www.nitindermohan.com/
>> > > >
>> > > > From: Sebastian Moeller via Starlink <starlink@lists.bu= fferbloat.net>
>> > > > Reply: Sebastian Moeller <moeller0@gmx.de>
>> > > > Date: 14. July 2022 at 14:35:16
>> > > > To: Mike Puchol <mike@starlink.sx>
>> > > > Cc: Dave Taht via Starlink <starlink@lists.bufferbloat.= net>
>> > > > Subject: Re: [Starlink] starlink at sea
>> > > >
>> > > >> Hi Mike.
>> > > >>
>> > > >> Thanks a lot. This is intersting.
>> > > >>
>> > > >> > On Jul 14, 2022, at 14:02, Mike Puchol <= ;mike@starlink.sx= > wrote:
>> > > >> >
>> > > >> > The uplink is an OFDM signal with 128 subc= arriers, looking at the signal in the time domain reveals a frame length co= rresponding to 14% (from memory, 1,1 us frame vs 6.7 us pause). I have two = terminals 1 meter apart and they can each achieve 30 Mbps at the same time = over the same uplink channel. I would expect the satellite to assign a part= icular set of slots to a terminal.
>> > > >>
>> > > >> So assuming the 30 Mbps being gross rate and no= t measured goodput:
>> > > >>
>> > > >> 30Mbps -> 30 / (1.1/(6.7+1.1)) =3D 212.73 Mb= /s while actively sending, and
>> > > >> 1000000=C2=B5s/s / (6.7+1.1)=C2=B5s =3D 128205.= 128205 slots/sec
>> > > >> (30 / (1.1/(6.7+1.1))) * 1000^2 / (1000000 / (6= .7+1.1)) =3D 1659.27 bits/slot 1659.27/8 =3D 207.41 Bytes/slot
>> > > >>
>> > > >> with 128 subcarriers that would be approximatel= y an average
>> > > >>
>> > > >> 1659.27/128 =3D 12.96 or ~ 13 bit/subcarrier >> > > >>
>> > > >> if all carriers are loaded equally (which is un= likely, I expect some re-arrangement ot bits between subcarriers to account= for different levels of noise and what not).
>> > > >>
>> > > >>
>> > > >> > If there are any OFDM blind analysis exper= ts in the room, shout!
>> > > >>
>> > > >> Please do!
>> > > >> Regards
>> > > >> Sebastian
>> > > >>
>> > > >> >
>> > > >> > Best,
>> > > >> >
>> > > >> > Mike
>> > > >> > On Jul 14, 2022, 13:33 +0200, Sebastian Mo= eller <moeller0@gmx= .de>, wrote:
>> > > >> >> Hi Mike,
>> > > >> >>
>> > > >> >>> On Jul 14, 2022, at 13:15, Mike Pu= chol via Starlink <starlink@lists.bufferbloat.net> wrote:
>> > > >> >>>
>> > > >> >>> On the multiple terminals, I have = verified that the duty cycle of a consumer terminal is 14%, thus, you could= have 7 terminals on a single uplink channel with some guard time.
>> > > >> >>
>> > > >> >> Could you elaborate how that works.how= the terminals will be interleaved in that situation?
>> > > >> >>
>> > > >> >> Regards
>> > > >> >> Sebastian
>> > > >> >>
>> > > >> >>
>> > > >> >>> I have seen 30 Mbps up, so you=E2= =80=99d be able to push 210 Mbps in uplink, or a spectral efficiency of abo= ut 3.4 bps/Hz.
>> > > >> >>
>> > > >>
>> > > >> _______________________________________________=
>> > > >> 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
>> > >

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
Starlink mailing list
Starlin= k@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
--0000000000000086a805e3c59ce9--