Satellite Internet relative security

Joshua Judson Rosen rozzin at hackerposse.com
Sun Aug 27 00:26:43 EDT 2017


On 08/26/2017 09:46 PM, James A. Kuzdrall wrote:
> On Friday 25 August 2017 13:04:11 Brian St. Pierre wrote:
>> On Fri, Aug 25, 2017 at 11:56 AM, James A. Kuzdrall <gnhlug at intrel.com>
>>
>> wrote:
>>>     Does Linux have any special problems interfacing with the dish
>>> equipment?
>>> Is a standard Ethernet connection enough, or must they install software
>>> on the Linux computer?
>>
>> I had service through Hughes for a couple years around 2010 or so. They
>> give you a modem, connect a cable from dish to modem, connect ethernet
>> cable from computer to modem, and it's more or less like having dsl or
>> cable with horrible latency. You don't need to install anything on linux,
>> though you may get hassled by customer support if you have to call in.
>>
>> The latency is bad. You can end up with no service or degraded performance
>> in heavy rain, snow, and/or if there's any snow/ice buildup on the dish. I
>> think they still have a daily usage cap, but I'm not sure. It's probably
>> better than dialup if you don't care about the latency, but I'd consider it
>> a last resort. If there is still a usage cap, you might look at whether a
>> mobile data plan and tethering is a viable alternative.
> 
>     Latency would be a pain.  Since the military controls combat drones via 
> satellite, I assumed it would be fast.  It could be that the commercial links 
> go through more processing hubs, but how about the suggestion that it has a 
> built-in latency?


Speed ("fast" or "slow") and latency ("quick" or "lagging") are two completely different things
Satellite Internet (when it's working) is *both* high-speed *and* high-latency,
and there's no contradiction there.

The latency doesn't so much have anything do with `more processing hubs';
it's just that routing everything through a geostationary satellite means the signals
ultimately need to travel roughly *100,000 miles* (round trip) before you can see
a response from whatever website or other service you're using. Even at *light speed*,
that's more than a half-second of delay.

Think about it this way: if you have a bunch of stuff to move from Nashua to Manchester by car,
and you're going to drive it there at 60 MPH, it's going to take something like 20 minutes, each way,
per trip. You can move your stuff *faster* by using a bigger car/truck and carrying more stuff
on each trip, but you can't do anything about the 20-minute *latency*. While you can increase
the overall `items shipped per day' rate, no specific item can make the trip in less
than 20 minutes--and if you need to convey items *back* to complete an exchanges,
then no exchange can complete in less than 40 minutes because that's how much latency
is `built into the system'.

And if for some reason you go from Nashua to Manchester and back *by way of California*...,
again it doesn't matter how big a truck you have or how much it can carry at once,
you're still going to have *days* of latency if you take such a long route.

That's the thing about latency: it's pretty much always, by definition, `built in':
once you have latency, there's generally nothing you can do to work around it.
If you just have a slow (low-bandwidth) link, there are some things that
can be done to make more efficient use that limited bandwidth.

Having said all of that: some people find that high-speed + high-latency
links are unusable; other's probably find that they're perfectly fine.
You wouldn't want to be trying to remote control something *in real time*
over a satellite link, but there are things like sending e-mail or downloading large files
(or queuing up actions on a mostly-autonomous UAV!) where even an full extra second of *lag*
probably shouldn't make much of a difference....

-- 
Connect with me on the GNU social network: <https://status.hackerposse.com/rozzin>
Not on the network? Ask me for an invitation to the nhcrossing.com social hub!


More information about the gnhlug-discuss mailing list