> 3.8 meter ku band dual linear polarity compact cassegrain dish > a 5.5m dish
Are these receiver sizes in the range of what Starlink expects from users? I had in mind something more like a DirectTV dish. If the consumer dish sizes are indeed smaller, how does that affect the discussion about jitter and other aspects of link quality?
The starlink cpe is indeed in the category of directv dish sized.
With only a tiny bit of the relevant subjects under my belt, I would expect the metrics to be significantly worse using a much smaller dish. But it seems like you're suggesting Starlink could achieve similar metrics on a smaller dish? I'm curious how that works. Apologies if I'm misunderstanding.
Note that may be true for one bird in Afghanistan, but the path length isn't exactly the same everywhere, nor are the delays of all modulaiton schemes.
For instance our site in Germany was more than 15ms away by fiber from DE-CIX stuff in Frankfurt. The site in Singapore had better latency to any cdn or hosting operation that was in Singapore itself, but much worse if traffic had to find its way through the terrestrial submarine fiber internet to other places. End to end latency between Afghanistan-germany-seattle or Afghanistan-singapore-seattle was considerably different.
Yes, the position of the two end point sites on the sphere that is the earth will have slightly different speed of light times to a satellite in geostationary orbit. But 99% of that latency in the above 490ms figure is the extreme distance of the satellite, and not whether or not one site is slightly further down the sphere, as viewed from a theoretical observer sitting on the satellite.
It is also worth noting that modern scpc/mcpc modems can be intentionally configured to use more computationally "expensive" FECs, in a trade off of slightly more bps/Hz squeezed into a given sized slice of transport kHz, at the expense of a few ms higher latency. This is a network engineering design decision made when a link is first brought online. Modern modems and ASICs, FPGAs have made this less difficult than it used to be. If I can use an analogy for software developers, this is sort of like the speed vs file size trade off choice made between using gzip, bzip2, xzip, at different settings and compression levels.
Path length varies from ~34500km to ~42000km (~115ms to ~140ms). So, assuming an ideally placed teleport, from 115 * 4 = 460ms to 115 * 2 + 140 * 2 = 510ms speed of light delay on round trips. This is why I said I found 492ms to be an amazingly over-precise number. Just call it 500ms. :P
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).
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.
Example: at one location, a 3.8 meter ku band dual linear polarity compact cassegrain dish in somalia, a 200W BUC+SSPA, good quality norsat PLL LNB, a cdm760 modem. Ten MHz of transponder space occupied total. Other end, a 5.5m dish with similar gear on it in a teleport in Cyprus.
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's how that dedicated capacity can get sliced up and shared that is the most common cause of packet loss, jitter and high latency in geostationary based two way satellite IP links.
The most common thing for a cheap VSAT isp to do is to acquire one chunk of Ku transponder capacity (let's say about $8000 a month worth), install something like an idirect hub with line cards in it, and sell access to individual end users in $developingnation at an 8:1 oversubscription ratio or more. Meaning that an end user vsat terminal might see 495ms at a lucky time when its peers in the same network were not also moving traffic, but could also often see latency anywhere from 500 to 850 during busy periods.
Now that same 8000 bucks a month of transponder space could equally well be assigned to a single high priority end user with money to pay, in which case they would never see above 495ms. Or it could be oversubscribed to all hell, such as if the ISP wanted to sell $280/month service to a bunch of very cost conscious end users in a developing nation environment who can only afford very cheap VSAT terminal hardware (one 1.2m fiberglass compression molded reflector, a 4W BUC, and an idirect modem) and minimal monthly ongoing payments. In which case each user will be in a 16:1 or worse oversubscribed network.
The economics of making a 5500 kilogram $200 million satellite in geostationary orbit pay for itself, before its lifespan is done in 15 years, are not favorable. If you ever want to truly be shocked go price the $ per Mbps per month that results from the 1:1 dedicated setup I described above.
On the topic of what the average hn reader considers "satellite internet". Based on consumer experience with the absolute cheapest consumer grade ku and Ka band vsat terminals in the usa, they almost 99% of the time mean Hughesnet or viasat/wildblue. Very few people actually have money or reason to lay their hands on real two way satellite stuff. Generally if you work for a company that needs something like a $3500/month link for a mine in Nunavut you're paying some third party experts to implement it.