← Back to context

Comment by x87678r

5 years ago

Now do WFH with remote desktop that is on a shared VM a few states away with a bunch of other devs. Its horrible.

With lockdown keeping me at home, and having to RDP to work over a VPN, I've gone quite far down the rabbit hole this year experimenting with low latency keyboards (1000Hz USB polling, configurable debounce times), gaming mice and high refresh rate monitors (125Hz+), all to try and make my remote experience feel more local.

The threshold for me (and most people I think) is about 110ms between key strike and something appearing on the screen before something feels non-local and disembodied... which is good because I found I could get down to ~40ms local response time on a decent windows box. My 2015 macbook is about ~120ms for the terminal app.

That leaves 70ms latency budget to play with which can accommodate the the RDP overhead (~50ms) and the network hop (~10ms for me).

This whole journey started with me wondering if I should pay a small fortune for a better network connection, before I realised that most of the latency was in my keyboard and monitor!

I even built a Arduino Leonardo gadget to measure the lag systematically and some pcap software to spot the RDP packets on the wire. The code's pretty shoddy but it does the trick! You can see it and an example result with RDP here:

https://github.com/willmuldrew/lagmeter

Another big factor in the experience is jitter - so it's a good idea to ensure everything is plugged in if you can. Mice, keyboards and ethernet.

In essence, even if you have to RDP/remote into work, potentially you can still make it feel pretty local - don't give up hope!

  • Nice, I didn't think that but it makes sense that network hop isn't so slow now. I am surprised RDP to work isn't as slow as I feared, the shared server they give us is a different problem. :)

I have a project right now where I have to connect to a VPN, then remote-desktop to a "jumper PC" that's dual-homed via VNC to a segregated PC running Windows XP on a manufacturing tool we recently got out of mothball to backfill Covid supply chain gaps. On the plus side - the ancient version of Visual Studio on that tool is surprisingly snappy!

All my coworkers remote desktop into their workstations at the office from a laptop at home to do dev work. I can't do it. vscode remote development extension has been my savior when I need to code locally and then flip over to RDP to run the deployment from a specific environment (the office)

  • The workflow requires RDP? That sucks. Should build some command line equivalent.

    • The dev desktops in the office are a controlled environment that can be locked down. We need that as we work in closely regulated industries handling potentially sensitive data.

      At least until we arrange for everyone to have company provided dedicated work laptops which we can (mostly) lock down to the satisfaction of our clients and their auditors, but the switch to mostly remote working this year happened at roughly the same time as budgets were squeezed a bit (bet you can guess why!) so that hasn't happened across the board yet.

      Allowing RDP from non-secured devices "for the time being" is iffy, but we are getting away with it due to the circumstances.

Our development environments have been azure VMs for ages.

Latency is not really an issue to be honest. I think ping is about 15ms which is much less than the lag in this article. Right now I'm using the horrible, 2012-era work laptop with just Chrome running and there are delays typing this comment into HN which is a super lean site as it is.

The main downsides are actually

* crap single-threaded performance (don't think Azure has VMs over 3ghz except maybe the highly expensive GPU ones)

* Slow IO

* Video and audio over RDP really doesn't work.. no hardware graphics accel either... reduced ability to work on multimedia, we had one webapp where WebGL wound up behaving differently which we didnt

Citrix has made a whole thing out of speeding up this scenario. It's a big part of why customers still use their software despite their other numerous failings.