[acdha]

I agree in general but I do blame Citrix for some foot-guns. The Citrix admins at my employer have never figured out how to configure it to get keyboard latency below ~120ms (on a gigabit LAN), and the silly health meter always reports the connection as excellent. This is mostly on them - in classic enterprise IT thinking, if it’s not down your job is done - but I’m somewhat disappointed that it’s even possible to configure it to have latency twice that of a modem.

[zasdffaa]

A 120ms should feel immediate. IIRC anything under 300ms feels instant.

[babypuncher]

This is just flat out wrong. Any seasoned gamer can feel the difference between a few tens of milliseconds.

300ms would render most video games unplayable.

I see this claim a lot and it's making me want to build a website that gives you some common interactions (moving a mouse cursor, pressing a button) with adjustable latency so people can see just how big of an impact seemingly small amounts of lag have on how responsive something feels.

[rollcat]

https://aresluna.org/keyboard-secrets/typing-delay/

[Izkata]

After using xterm for years, I don't like gnome-terminal anymore because its lag while typing has become noticeable. It's right around 30ms on this site, and xterm around 10-20ms.

[qu4z-2]

This is great, thanks. I'll have to remember it next time someone makes that bizarre claim.

[petercooper]

Just running my display at 60Hz vs 30Hz is enough. The pointer feels extremely laggy at 30Hz, despite that being a higher refresh rate than a movie.

[account42]

Movies always get brought up in framerate discussions but they are a completely different beast compared to interactive computer applications because

a) movies are not interactive so latency is not a concern, only fluidity is

b) movies come with pre-applied motion blurring to hide the low framerate (which is different from fake motion blur applied in some games)

c) 30 FPS is atrocious even for movies and I wish higher framerate movies had gotten more common

[chris37879]

30 vs 45 fps on my steam deck feels night and day different, it's amazing how much small jumps like that can help.

[andrewflnr]

Then have an estimation challenge mode, where it picks a random latency and you have to guess within 50ms what it is. Seriously though, that sounds both fun and useful.

[Fire-Dragon-DoL]

If you had 300ms latency, back when I played League of Legends "your ISP is having problems today and you cannot play". Anything above 70 is considered very bad

[Scramblejams]

Sounds excellent. I would send that link around to a lotta people.

[zasdffaa]

That was a bad post. The figure of 300ms was from memory. I guess it's complex but for games shmup games (https://www.pubnub.com/blog/how-fast-is-realtime-human-perce...):

"

...for Massive Multiplayer Online Gaming (MMOG), real-time is a requirement.

As online gaming matures, players flock to games with more immersive and lifelike experiences. To satisfy this demand, developers now need to produce games with very realistic environments that have very strict data stream latency requirements:

    300ms < game is unplayable
    150ms  < game play degraded 
    100ms < player performance affected
    50ms   > target performance
    13ms    > lower detectable limit

"

But this is real-time gaming. Typing should be less demanding, I'd think.

Edit: also https://stackoverflow.com/questions/536300/what-is-the-short...

[eloisant]

> Typing should be less demanding, I'd think.

Not really, unless you're the kind of guy working in Cobol and who is used to typing with latency.

I've seen Cobol developers just ignoring the latency, keeping typing because they know what they've typed and it doesn't matter that it's slow to show up on screen.

[toast0]

Working with latency like that also requires the system to be predictable. If you're expecting auto complete but not confident in what it'll show, you've got to wait, if you're not sure if the input will be dropped if you type ahead too much, you've got to wait. If you need to click on things, especially if the targets change, lots of waiting.

If the system works well, yeah, you can type all the stuff, then wait for it to show up and confirm. 'BBS mode' as someone mentioned.

[NoGravitas]

> I've seen Cobol developers just ignoring the latency, keeping typing because they know what they've typed and it doesn't matter that it's slow to show up on screen.

I used to do that (not in COBOL), typing into a text editor in a terminal over a 2400-baud modem. Like the other commenter said, you get used to it, but it requires a certain predictability in your environment that you don't get in modern GUIs.

[viridian]

Generally I think of it in terms of number of frames @ 60 fps.

Anything below one frame (16.66ms) and whether or not any sort of real feedback is even received (let alone interpreted by the brain) becomes a probability density function. With each additional frame after that providing more and more kinesthetic friction until you become completely divorced from the feedback around 15-20 frames.

[flutas]

Just a heads up for others trying to read this, I think the < and > are backwards.

[acdha]

That’s off by about an order of magnitude – highly skilled humans can see and react in less than 120ms. One thing which can complicate discussion on this is that there are different closely related things: how quickly you can see, understand, and react is slower than just seeing which is slower than seeing a change in an ongoing trend (that’s why you notice stutter more than isolated motion), and there are differences based on the type of change (we see motion, contrast, orientation, and color at different latencies due to how signals are processed starting in the cortex and progressing through V1, V2, V3, V4, etc.) how focused you are on the action (e.g. watching to see a bird move is different than seeing the effect of something you’re directly controlling). Audio is generally lower latency than visual, too.

All of this means that the old figures are not useful as a rule of thumb unless your task is exactly what they studied. This paper notes how unhelpful that is with ranges from 2-100ms! They found thresholds around 25ms for some tasks but as low as 6ms for some tasks.

https://www.tactuallabs.com/papers/howMuchFasterIsFastEnough...

Keyboard latency is one of the harder ends of this spectrum: the users are focused, expecting a strong (high contrast, new signal) change in direct response to their action, and everything is highly trained to the point of being reflex.

When I’m typing text, I’m not waiting for the change to hit a key outside of games but rather expecting things like text to appear as expected or a cursor to move. Awhile back I tested this and the latency difference between VSC’s ~15ms key-to-character was noticeably smoother compared to 80+ms (Atom, Sublime) and the Citrix system I tested at 120-150ms (Notepad is like 15ms normally) was enough slower that it forced a different way of thinking about it (for me, that was “like a BBS” because I grew up in the 80s).

n.b. I’m not an expert in this but worked in a neuroscience lab for years supporting researchers who studied the visual system (including this specific issue) so I’m very confident that the overall message is “it’s complicated” even if I’m misremembering some of the details.

[mm007emko]

Not my experience. 300ms is noticeable and very annoying. 120ms does not feel instant to me.

[NoGravitas]

300ms is a "long press" on a key on Android, and an eternity on an actual keyboard.

[dan-robertson]

The parent comment may be talking only about the network or Citrix components in the critical path. You also have to wait to get keyboard input (often 10s to many 10s of ms) and for double-buffering or composition (you might get updates and render during frame T, flip buffers to reach the OS compositor for frame T+1, have the compositor take another frame to render that and send it to the screen for frame T+2, though this is a bad case for a compositor, you may be paying the double buffering or flu latency twice). And it can take a while for modern LCD screens to process the inputs (changes towards the bottom of the screen take about a frame longer to display) and to physically switch the pixels.

120ms end-to-end without Citrix would be quite achievable with many modern systems (older systems (and programs written for them) were often not powerful enough to do some of the things that add latency to modern systems). So if Citrix 120ms we already get up to your ‘not immediate’ number.

But I think you’re also wrong in that eg typing latency can be noticeable even if you don’t observe a pause between pressing a key and the character appearing. If I use google docs[1] for example, I feel like I am having to move my fingers through honey to type - the whole experience just feels sluggish.

[1] this is on a desktop. On the iPad app I had multiple-second key press-to-display latency when adding a suggestion in the middle of a medium-sized doc.

[pleb_nz]

Divide those figures by 10 might be closer to being accurate. 120ms is quite noticable. I know as I need to adjust latency out of Bluetooth headphones for recording. Recording with those latencies sounds like a disaster and is very very much noticable even with sounds let alone vision

[zasdffaa]

While my post was wrong, in fairness the context was specifically about keyboards. Nothing to do with audio. I suppose I should have been explicit but the context was keyboard entry.

[pleb_nz]

In my experience visual and feeling type things like typing have even stricter tolerances for timings is what I meant to say. If audio has a delay, visually noticing a delay will at least be as equal if not more noticable at a specific ms

[imtringued]

We aren't talking about website loading speeds. This is about how quickly your mouse cursor moves in response to mouse movements and that latency needs to be 16ms or less.

Personally I can get latency down to 200ms over the internet into a remote datacenter with WebRTC. The challenge however in practice is that running a CPU without a GPU will eventually starve the CPU because it has to do intensive things like run a 1080p video at 60fps which aren't feasible on a CPU only machine. This CPU load will then slow down the video encoder and overall responsiveness (no, responsiveness doesn't mean a mobile layout here) of the remote desktop.

[dragonwriter]

That contradicts fairly long-held understanding:

https://www.nngroup.com/articles/response-times-3-important-...

[matheusmoreira]

Anything above 50 ms is absolutely noticeable and should be considered a bug.

[Nimitz14]

Under 100ms feels immediate. More doesnt.