Re: [Starlink] starlink at sea

[Nathan Owens <nathan@nathan.io>]

[-- Attachment #1: Type: text/plain, Size: 7553 bytes --]

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’t 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° 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
> 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 <mohan@in.tum.de>, 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 <mohan@in.tum.de>
> >> Reply: Nitinder Mohan <mohan@in.tum.de>
> >> Date: 14. July 2022 at 15:05:42
> >> To: Jared Mauch <jared@puck.nether.net>
> >> Cc: Dave Taht via Starlink <starlink@lists.bufferbloat.net>, Mike
> Puchol <mike@starlink.sx>
> >> 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 <jared@puck.nether.net>
> >> > Reply: Jared Mauch <jared@puck.nether.net>
> >> > Date: 14. July 2022 at 14:57:25
> >> > To: Nitinder Mohan <mohan@in.tum.de>
> >> > Cc: Mike Puchol <mike@starlink.sx>, Dave Taht via Starlink <
> starlink@lists.bufferbloat.net>
> >> > Subject:  Re: [Starlink] starlink at sea
> >> >
> >> > > I haven’t 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_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 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 connected
> 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 <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 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 of
> slots to a terminal.
> >> > > >>
> >> > > >> So assuming the 30 Mbps being gross rate and not measured
> goodput:
> >> > > >>
> >> > > >> 30Mbps -> 30 / (1.1/(6.7+1.1)) = 212.73 Mb/s while actively
> sending, and
> >> > > >> 1000000µs/s / (6.7+1.1)µs = 128205.128205 slots/sec
> >> > > >> (30 / (1.1/(6.7+1.1))) * 1000^2 / (1000000 / (6.7+1.1)) =
> 1659.27 bits/slot 1659.27/8 = 207.41 Bytes/slot
> >> > > >>
> >> > > >> with 128 subcarriers that would be approximately an average
> >> > > >>
> >> > > >> 1659.27/128 = 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’d be able to push 210 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
>

[-- Attachment #2: Type: text/html, Size: 12146 bytes --]