Re:SpaceX Starlink has some hiccups as expected, but users a...
by Dylan16807 on Wednesday November 18, 2020 @03:17AM
(#25134308)
So you had physical problems with the signal, and you had jitter, but the physical problems don't directly or inevitably cause jitter. The cause of the jitter has to have been a flawed method of compensating for the signal problems.
Even when you can see a mountain multiple times at once, the apparent distance to the mountain is going to have almost no variance as it shimmers around.
Let me see if I can answer some of this.
We were on a 1:1, eventually. Tried the 8:1 (or something like that) at first and it was terrible.
Latency was almost always, like you said, almost exactly 495ms at the link. However, we'd suffer transient jitter that directly correlated to weather in the atmosphere. Essentially, satellite communication is a laser (parabolas ftw), so this made sense at the time. Correlation doesn't necessarily mean causation, but it was annoyingly correlated.
I only made this correlation because my "day job" in the military had a lot to do with radar, microwave antennas, and optics. So, I'd observe the refraction personally (being able to see mountains as clutter for example, when the radar rays were pointed well over the mountains) and then notice the observed jitter on the network. Not to mention people coming to tell me how unusable Skype was at the moment and could I fix it please?
No offense, but you probably don't see this at your level as a network engineer unless you're "boots on the ground." When you're there and easily accessible, people will come complain to you when any and every little thing that goes wrong and "their wife is threatening to leave them and they can't even have a conversation, omg, fix it right now plz."
In a more corporate setting, people are far less likely to complain about transient issues because they fix themselves before the complaint can be made, or if they do, it's easy to dismiss as other issues.
To be honest, we had those other issues as well. QoS was a thing, and constantly battling bittorrent clients and their users was also a thing. But those issues were usually only during the evenings when lots of people were trying to call home and get on Facebook. I'm talking about when none of those issues were at play, such as late at night or during the day.
The UDP solution was directly related to periods of saturation, specifically I built a custom transparent proxy forked from Squid. It's sole job was to act as a mediator between a server back in the US that did a few things:
1. On the Afghanistan side, it would wrap the HTTP(S) request packet and send it via a TCP control channel to the server in the US.
2. On the US side, it would do some image compression (if applicable) and other things to the response to make it smaller (in bytes).
3. On the US side, it would also keep track of user flows and how much bandwidth each user got, and spit back UDP packets, reserving a dynamic % of bandwidth for control and unregulated packets. There was also an open TCP control connection for sending back smaller things that fit within a few packets.
4. On the Afghanistan side, it would put all these packets together to reform the stream, keeping track of any dropped packets (rare) and then forwarding the completed stream (or once the buffer was full) to the user at 100mbps. If any were dropped, it sent back a bitmap over the open TCP connection to have those frames retransmitted via TCP and then inserted into the stream before going to the client.
It worked fantastic for things like youtube, since the subscriber could make full use of their subscribed bandwidth with a half-second delay after clicking a link. The only things that didn't use that system were things like Skype. We never really had transport-related congestion issues after this was built as a hack, over several weeks. To be honest, it probably would have worked just fine by forwarding over already open TCP connections to the back-end server and giving each subscriber a dedicated stream. However, time in the desert is a premium and once something works good-enough, it pretty much stays that way forever.
> If the person I'm replying to isn't willing or able to clarify whether they were in a contended, or dedicated network, or specify the gear, it's hard to say exactly why they're seeing jitter. But I can quite confidently say that excursions above 495ms are not something seen in a dedicated network.
It was over ten years ago at this point, so I don't remember the exact models of anything. I do remember it was ku-band, but that's not exactly helpful. :) I sold everything off after getting sent back to the US for a medical discharge. The source was also lost in that pretty crazy time of my life, mostly due to the laptop ceasing to exist. The code still probably exists in SVN somewhere (Google Code, probably).