RDP over satellite

The typical example where satellite latency drastically affects performance is given publicly as online gaming.
However more generally relevant and a weightier argument surely is its effect on home working. Typically a worker from home will remote onto their desktop (or is that only me?)
Fairly old posts across the internet (2006ish) state that remote desktop across satellite is just a non-starter due to latency.
Can anyone confirm that that is still the case - that remote desktop over satellite is still just impossible?

It will work but yes latency will be a killer, i.e. following a mouse track if its windows will be a pain. Similar for remote linux sessions where you end up having to guess what you are typing.

Not impossible, but something best left to emergencies, have used it over transatlantic links many years ago (150 to 200ms) and so long as you did not rush would be ok. Raise that to 800ms and will be a pain.

Gaming is used as the example usually as its the one people most easily understand.

In reply to a post by SLAMDUNC:

The typical example where satellite latency drastically affects performance is given publicly as online gaming.
However more generally relevant and a weightier argument surely is its effect on home working. Typically a worker from home will remote onto their desktop (or is that only me?)
Fairly old posts across the internet (2006ish) state that remote desktop across satellite is just a non-starter due to latency.
Can anyone confirm that that is still the case - that remote desktop over satellite is still just impossible?

It's doable but not pleasant. I certainly wouldn't say it's viable for doing everything.

I work from home and do not RDP into my desktop as I don't have one. I believe this is a fairly common thing now. If employers allow staff to work from home they generally supply a laptop and VPN access to the corporate network.

In my case most of what I access is 'in the cloud' anyway and I believe that's where things are increasingly going. I've not heard of using RDP to a desktop as a substitute for being in the office if I'm honest. Seems inefficient.

Well, it's a VPN then RDP onto (powerful) desktop. No point distributing 16GB RAM laptops to staff when they just need a browser on the family laptop to get onto their secure, configured machine at work.

Anyway thanks for that - although inline for a SuperfastEssex satellite upgrade in 2016 no way will I be taking it up.

Company I used to work for had a satellite connection and used RDP heavily.
Their solution was to install a basic <1Mbps ADSL and route all RDP traffic over that to reduce the latency. Any other traffic (browsing, downloading etc) was routed over the satellite.

A number of companies use thin clients (either citrix style or VDI) in which case you are RDPing on to a server that is running your instance of a virtual desktop. That isn't good over high latency connections.

In reply to a post by MrSaffron:

have used it over transatlantic links many years ago (150 to 200ms) and so long as you did not rush would be ok. Raise that to 800ms and will be a pain.

ADSL over Atlantic then leased line at head office was okay for a me a couple of years ago. You could feel that it wasn't quite as responsive but not enough to be an issue.

Well I foud something official - the BDUK satellite trial page
http://www.primetech.co.uk/bduk-satellite-broadband-...
has (slightly optmistic?) information about useability.

Some of those schemes promote the idea of just one satellite dish in a village, shared across all the houses using wireless. So each person gets a share of the bandwidth. This keeps the costs down.

I personally think the idea is very poor, but clearly better than no internet connection at all.

I wouldn't try it. Working on servers over in Australia and Singapore with a ping of 1000ms is just a non starter, satellite is similar.

I used to work for a company that deployed satellite connections to mobile vehicles, who used a variety of services such as RDP, Logmein, VPN over satellite.

Latency should be more like 550-650ms, 800ms indicates a contented link.

It's useable for RDP, it is a little laggy but not insurmountable.

Logmein works a bit better.

VPN is fine as long as it's SSL not IPSec, as the sat modem will do TCP Ack acceleration which won't work for IPSec.

You can simulate it with this tool:

https://jagt.github.io/clumsy/

Add yourself ~300ms of latency in each direction, you will then see pings in the satellite sort of range. RDP to something and see how you feel it is.

Sat should be slightly better than this simulation as there is nothing doing TCP Acks.

In reply to a post by SLAMDUNC:

that remote desktop over satellite is still just impossible?

Only possible solution is using a Citrix product (e.g. XenApp) with its local echo feature enabled. (Speed Screen). This is where the Citrix client responds to your screen quickly - faking the response.

Doesn't work for all applications.

In reply to a post by SLAMDUNC:

Well I foud something official - the BDUK satellite trial page
http://www.primetech.co.uk/bduk-satellite-broadband-...
has (slightly optmistic?) information about useability.

Lol, that inspires confidence. Someone should explain to them the difference between Gb and GB.

I mean 10GB allowance is pretty paltry for £33 pcm but 10Gb is derisory

In reply to a post by brandscill:

I wouldn't try it. Working on servers over in Australia and Singapore with a ping of 1000ms is just a non starter, satellite is similar.

Yikes; I'd be asking some serious questions of the ISP if round trip to Singapore and Australia is a second.

carl@HP-Microserver:~$ ping www.telstra.com.au
PING www.telstra.com.au (58.162.89.137) 56(84) bytes of data.
64 bytes from 58.162.89.137: icmp_seq=1 ttl=239 time=325 ms
64 bytes from 58.162.89.137: icmp_seq=2 ttl=240 time=328 ms
64 bytes from 58.162.89.137: icmp_seq=3 ttl=240 time=327 ms
64 bytes from 58.162.89.137: icmp_seq=4 ttl=239 time=328 ms
64 bytes from 58.162.89.137: icmp_seq=5 ttl=240 time=327 ms
^C
--- www.telstra.com.au ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 5765ms
rtt min/avg/max/mdev = 325.170/327.286/328.798/1.220 ms

carl@HP-Microserver:~$ ping www.singtel.com.sg
PING www.wip.singtel.com.sg (203.126.100.199) 56(84) bytes of data.
64 bytes from 203.126.100.199: icmp_seq=1 ttl=235 time=280 ms
64 bytes from 203.126.100.199: icmp_seq=2 ttl=235 time=275 ms
64 bytes from 203.126.100.199: icmp_seq=3 ttl=235 time=275 ms
64 bytes from 203.126.100.199: icmp_seq=4 ttl=235 time=288 ms
64 bytes from 203.126.100.199: icmp_seq=5 ttl=235 time=288 ms
^C
--- www.wip.singtel.com.sg ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 275.014/281.401/288.495/5.886 ms