Hacker News Reader

Comment by romwell | Hacker News Reader

Latency is criminally neglected in nearly every piece of tech that I get to use.

Over the years, the number of transistors on the chip has grown - as has the lag.

Everything is laggy. Touchscreens are laggy (especially in embedded devices, like coffee machines). Webpages are laggy. USB keyboards are laggy, way more laggy than ones on Apple II [1].

And of course, wireless audio is obnoxiously laggy.

So much for removing the headphones jack.

[1]https://danluu.com/input-lag/

View on HN

I just reinstalled Win10 (21H1 build) after SSD crash, previous build 1511 was from 2015 with disabled Windows Update (no patches for 6 years).

In build 1511 Win key opens Start menu instantly every time. In 21H1 SearchApp.exe process (120MB btw) is suspended and takes ~1 second (4GHz Intel) to resume before Start menu is allowed to show up :o You cant just disable SearchApp because it turns out Win10 performs actual search _every time_ you open start menu and will show empty Tiles otherwise. SearchApp suspends ~5 seconds after closing Start menu.

Win10 Taskbar has a hover time set to 400ms by default. You used to be able to edit MouseHoverTime and ExtendedUIHoverTime, afaik this no longer has effect and you are left with an arbitrary delay for thumbnail preview (couple hundred milliseconds).

and those are the most obvious every day delays in up to date freshly installed Windows 10 :o

Check if this has anything to do with memory compression. I think at some point windows 10 decided to compress memory (even if it has lots on hand) and it can lead to such delays. It shouldn't happen all the time though, just first time you access something in a awhile.

I've tried to set my kids up to watch movies in the car during long road trips, but the 10+ second bluetooth delay is brutal. Thankfully, we still have the headphone jack for wired audio.

Android, and not using VLC to adjust audio delay?

No, it's an iPad. Have not used VLC for iOS, but I might try. Luckily, the wired aux input has been working well enough.

Apple won't let VLXC ship certain codecs (something like that) so VLC on iPad is unfortunately not as super as elsewhere.

I don't disagree with you in general and I find the lack of focus on latency very frustrating (though the proliferation of 120hz screens seems to indicate that there's hope)

But with regard to the Dan Luu post I've tried to recreate his findings and maybe things have gotten better because with 170hz monitor and a run of the mill gaming keyboard I'm getting keypress to photon latencies in windows gVim of about 35ms as measured with a high speed camera.

This is made irrelevant for 90% of users who then use their keyboard & monitor in Discord, VS Code, and dozens of other JS-powered programs and sites.

sigh JS is imperfect but it doesn't just make everything it touches slow. I would be very surprised if in Discord for example any JS was blocking between you pressing a key and the key appearing in your text box.

In fact I took the time just now to run a few samples in Discord and it's looking like I'm getting the same 35-40ms keypress to photon latency as gVim with one 80ms outlier out of the 5 runs I did.

The difference is very noticeable on a less-than-new CPU (my x240 with an i7 4600U for example) when the text input triggers other UI changes. Even on my Ryzen 3600, switching channels in Discord has visible lag, regardless of network activity.

Compare this to any operation in Sublime Text/Merge and the difference is obvious.

The implication is also that more battery power is used for every action (not to mention vastly more memory), which matters for machines of any capability; but these are not latency-related concerns.

Reply on news.ycombinator.com