[Starlink] Starlink hidden buffers
Sebastian Moeller
moeller0 at gmx.de
Sun May 14 05:06:00 EDT 2023
Hi Ulrich,
silly question, does starlink operate using fixed geographical cells and are CPE/dishies assigned to a single cell? In which case handover would not have to be so bad, the satellite leaving a cell is going to shed all its load and is going to take over the previous satellite's load in the cell it just starts serving. Assuming equal "air-conditions" the modulation scheme should be similar. So wouldn't the biggest problem be the actual switch-over time required for dishies to move from one satellite to the next (and would this be in line with the reported latency spikes every 15 seconds)?
> On May 14, 2023, at 10:43, Ulrich Speidel via Starlink <starlink at lists.bufferbloat.net> wrote:
>
> On 14/05/2023 6:55 pm, David Lang wrote:
>>
>> I just discovered that someone is manufacturing an adapter so you no longer have
>> to cut the cable
>>
>> https://www.amazon.com/YAOSHENG-Rectangular-Adapter-Connect-Injector/dp/B0BYJTHX4P
>>
> I'll see whether I can get hold of one of these. Cutting a cable on a university IT asset as an academic is not allowed here, except if it doesn't meet electrical safety standards.
[SM] There must be a way to get this accomplished with in regulations if the test requiring this is somehow made part of the experiment, no? (Maybe requires partnering with other faculties like electrical engineering to get the necessary clout with the administration?)
> Alternatively, has anyone tried the standard Starlink Ethernet adapter with a PoE injector instead of the WiFi box? The adapter above seems to be like the Starlink one (which also inserts into the cable between Dishy and router).
>
>> > Put another way: If you have a protocol (TCP) that is designed to reasonably
>> > expect that its current cwnd is OK to use for now is put into a situation
>> > where there are relatively frequent, huge and lasting step changes in
>> > available BDP within subsecond periods, are your underlying assumptions still
>> > valid?
>>
>> I think that with interference from other APs, WIFI suffers at least as much
>> unpredictable changes to the available bandwidth.
> Really? I'm thinking stuff like the sudden addition of packets from potentially dozens of TCP flows with large cwnd's?
[SM] But would these really be added to an already existing load?
>>
>> > I suspect they're handing over whole cells, not individual users, at a time.
>>
>> I would guess the same (remember, in spite of them having launched >4000
>> satellites, this is still the early days, with the network changing as more are
>> launching)
>>
>> We've seen that it seems that there is only one satellite serving any cell at
>> one time.
> But the reverse is almost certainly not true: Each satellite must serve multiple cells.
[SM] Which is not necessarily a problem if the half-pipe to the base-station has enough capacity for all the per-cell traffic aggregated?
>> But remember that the system does know how much usage there is in the
>> cell before they do the handoff. It's unknown if they do anything with that, or
>> if they are just relaying based on geography. We also don't know what the
>> bandwidth to the ground stations is compared to the dishy.
> Well, we do know for NZ, sort of, based on the licences Starlink has here.
>>
>> And remember that for every cell that a satellite takes over, it's also giving
>> away one cell at the same time.
> Yes, except that some cells may have no users in them and some of them have a lot (think of a satellite flying into range of California from the Pacific, dropping over-the-water cells and acquiring land-based ones).
[SM] But the coming satellite should have pretty much the same over-air capacity as the leaving satellite, no? Sure there can be some modulation changes, but I would guess the changes would typically be relatively small?
>>
>> I'm not saying that the problem is trivial, but just that it's not unique
> What makes me suspicious here that it's not the usual bufferbloat problem is this: With conventional bufferbloat and FIFOs, you'd expect standing queues, right?
[SM] I thought it had been confirmed that starlink uses some form of AQM so not a dumb FIFO?
> With Starlink, we see the queues emptying relatively occasionally with RTTs in the low 20 ms, and in some cases under 20 ms even. With large ping packets (1500 bytes).
>>
>> David Lang
> --
> ****************************************************************
> Dr. Ulrich Speidel
>
> School of Computer Science
>
> Room 303S.594 (City Campus)
>
> The University of Auckland
>
> u.speidel at auckland.ac.nz
>
>
> http://www.cs.auckland.ac.nz/~ulrich/
>
> ****************************************************************
>
>
>
>
> _______________________________________________
> Starlink mailing list
> Starlink at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
More information about the Starlink
mailing list