9 ms·
Hooray, with these changes, the tested setup finally manages to have a smaller input median latency (Console ~12 msec) than an Apple //e from 1983 (30 msec). It
by dwheeler 3y ago
Hooray, with these changes, the tested setup finally manages to have a smaller input median latency (Console ~12 msec) than an Apple //e from 1983 (30 msec). It only took 41 years:
https://www.extremetech.com/computing/261148-modern-computers-struggle-match-input-latency-apple-iie https://www.extremetech.com/computing/261148-modern-computer...
https://danluu.com/input-lag/ https://danluu.com/input-lag/
But wait! Not so fast (smile). This benchmark uses the compositor "raw Mutter 46.0", not GNOME Shell. Raw mutter is "a very bare-bones environment that is only really meant for testing."
In addition, this measurement is not end-to-end because it does not include keyboard latency. In this test, the "board sends a key press over USB (for example, Space)". Latencies just within a keyboard can go up to 60msec by themselves:
https://danluu.com/keyboard-latency/ https://danluu.com/keyboard-latency/
What are the true end-to-end numbers for the default configuration, which is the only situation and configuration that really matters? I wish the article had measured that. I suspect the numbers will be significantly worse.
I do congratulate the work of the GNOME team and the benchmarker here. Great job! But there are important unanswered questions.
Of course, the Apple //e used hardware acceleration and didn't deal with Unicode, so there are many differences. Also note that the Apple //e design was based on the older Apple ][, designed in the 1970s.
Still, it would be nice to return to the human resposiveness of machines 41+ years old.
- naikrovek 3y agoDealing with Unicode is not the challenge that people seem to believe it is. There are edge cases where things can get weird, but they are few and those problems are easily solved. What really got my goat about this article is that prior to the latest tested version of Gnome, the repaint rate was a fixed 40Hz! Whose decision was that?
- dwheeler 3y agoUnicode is more challenging when you're talking about hardware acceleration. On an Apple //e, displaying a new character required writing 1 byte to a video region. The hardware used that byte to index into a ROM to determine what to display. Today's computers are faster, but they must also transmit more bytes to change the character display. That said, I can imagine more clever uses of displays might produce significantly faster displays.
- hnlmorg 3y agoModern video acceleration wouldn’t copy 1 byte into video memory even if we stuck to ASCII. They have to blit those characters onto a surface in the required type-face. The extra few bytes for Unicode characters outside of the usual ASCII range is effectively a rounding error compared with the bitmap data you’re copying around.
- Twirrim 3y ago> What really got my goat about this article is that prior to the latest tested version of Gnome, the repaint rate was a fixed 40Hz! Whose decision was that? From a previous VTE weekly status message, leading up to the removal: "I still expect more work to be done around frame scheduling so that we can remove the ~40fps cap that predates reliable access to vblank information." (from https://thisweek.gnome.org/posts/2023/10/twig-118/ https://thisweek.gnome.org/posts/2023/10/twig-118/) So as with a lot of technical debt, it's grounded in common sense, and long since past time it should have been removed. It just took someone looking to realise it was there and work to remove it.
- naikrovek 3y agoThat’s a valid reason to choose a repaint rate, sure, but 40Hz? It’s halfway between 30Hz and 60Hz (yes, it is) but it seems like a poor choice, to me. 60Hz would have been much more reasonable. Also, why do userland applications need to know the monitor refresh rate at all? Repaint when the OS asks you to. Linux is a huge pile of crap pretending to be a comprehensive OS.
- Twirrim 3y agoYes, you're right, you're absolutely the smartest person in the industry, and absolutely everyone else doing all of this work has no clue what they are doing at all, and should absolutely bow down to your superior intellect. You not understanding why something was done, much with your orignal comments about 40hz, doesn't actually mean that it is wrong, or stupid. It means that you should probably spend time learning why before making proclamations.
- half-kh-hacker 3y agoThe methodology of the linked keyboard latency article including the physical travel time of the key has always irked me a little
- klysm 3y agoYeah that is definitely something that shouldn’t be included
- dotancohen 3y agoYet as a lover of Cherry Reds and Blues, in my opinion that time should most definitely be included. I am not a gamer, but I do notice the difference when I'm on a Red keyboard and when I'm on a Blue keyboard.
- emn13 3y agoMy initial gut reaction to this was - yeah, of course. But after reading https://danluu.com/keyboard-latency/ https://danluu.com/keyboard-latency/ - I'm not so sure. Why exactly should physical travel time not matter? If a keyboard has a particularly late switch, that _does_ affect the effective latency, does it not? I can sort of see the argument for post actuation latency in some specific cases, but as a general rule, I'm struggling to come up with a reason to exclude delays due to physical design.
- jagged-chisel 3y agoWe don’t all press keys in exactly the same way. How would you control for the human element?
- wtallis 3y agoVariance isn't a reason to simply ignore part of the problem.
- nomel 3y agoIt's a personal choice of input mechanism that you can add to the measured number. Also, the activation point is extremely repeatable. You become fully aware of that activation point, so it shouldn't contribute to the percieved latency, since that activation point is where you see yourself as hitting the button. This is the reason I don't use mechanical keyboards; I can't activate the key in a reasonable time.
- nialv7 3y agoI found the claim in the keyboard latency article suspicious. If keyboards regularly had 60ms key press to USB latency, rhythm games will be literally unplayable. Yet I never had this kind of problem with any of the keyboards I have owned.
- jasonjmcghee 3y agoI don't buy the 60ms latency either, but it's very easy to compensate for consistent latency when playing games, and most rhythm games choreograph what you should do in "just a moment" which is probably at least 10x more than 60ms
- hobs 3y agoSure, but not in FPS games, an additional 60ms you might as well as be down an entire standard deviation.
- bee_rider 3y agoOnly on movement inputs, which don’t (?) make as big a difference as aiming speed for most people I think. (I aim with my feet in first person shooters but I think that is a habit, maybe bad habit, picked up from playing on consoles for many years). Lots of people might not be good enough to care about missing 1-2 frames. One could also pre-load the wasd keys.
- codedokode 3y agoCould it be that the user simply learns to press a key slightly earlier to compensate for the latency? There is key travel time you have to account for anyway.
- rjh29 3y agoUse xfce. It is much more responsive than gnome.
- roomey 3y agoThe only problem is, if you use xfce for any length of time it is horrible going back to any other DM. Don't even attempt to use a modern windows install, you end up feeling that it is actually broken!
- lenerdenator 3y agoXfce always felt like Linux to me. Like sure, there are other interfaces, but this is the Linux one. I want an ARM laptop with expandable memory, user-replaceable battery, second SSD bay, and a well-supported GNU/Linux OS that has xfce as the UI - from the factory. That's the dream machine.
- djbusby 3y agoI put Gentoo+Xfce on Lenovo x86. Not sure what to do about touch display and rotate (fancy laptop). I've not tried an ARM laptop but this setup also works on RPi.
- bee_rider 3y agoIMO, better to install yourself. Too much potential for the manufacturer to add adware annoyances in a pre-install. Although, mine is an x86-centric take. There are occasionally issues around getting the right kernel for ARM, right? So maybe it would be helpful there.
- sodality2 3y agoXfce was my favorite until I found i3/sway. Even more responsive, and less mouse required since everything is first and foremost a keyboard shortcut, from workspace switching to resizing and splitting windows.
- Qwertious 3y agoLess mouse is required, but less mouse is permitted. It's just "less mouse". Sometimes I just want to use the mouse. (if you only want keyboard then i3/Sway is great though, obviously)
- Izkata 3y ago> a smaller input median latency (Console ~12 msec) than an Apple //e from 1983 (30 msec). > Still, it would be nice to return to the human resposiveness of machines 41+ years old. A while ago someone posted a webpage where you could set an arbitrary latency for an input field, and while I don't know how accurate it was, I'm pretty sure I remember having to set it to 7 or 8ms for it to feel like xterm.
- 2OEH8eoCRo0 3y agoInput latency or drawing to the screen? What's the latency of the Apple machine running GNOME?
- daghamm 3y agoWhy so negative? This is obviously an improvement, who cares if it is not perfect by your standards?
- iso8859-1 3y agoIt's an interesting observation, and it's constructive, providing actual data and knowledge. I downvoted you for negativity because you're providing nothing interesting.
- nequo 3y agoI found parent to be constructive as to tone rather than content and upvoted them for that reason. The constructive part of grandparent's point can be made without needlessly crapping on people's hard work.
- deleted 3y ago[deleted]
- ryukoposting 3y agoI'd argue that it's actually a good thing that the author ignored keyboard latency. We all have different keyboards plugged into different USB interfaces plugged into different computers running different versions of different operating systems. Throw hubs and KVMs into the mix, too. If the latency of those components varies wildly over the course of the test, it would introduce noise that reduces our ability to analyze the exact topic of the article - VTE's latency improvements. Even if the latency of those components were perfectly consistent over the course of the author's test, then it wouldn't affect the results of the test in absolute terms, and the conclusion wouldn't change. This exact situation is why differences in latency should never be expressed as percentages. There are several constants that can be normalized for a given sample set, but can't be normalized across an entire population of computer users. The author does a good job of avoiding that pitfall. The Mutter thing is interesting. The author holds that constant, and GNOME sits on top of Mutter, so I think it's reasonable to assume we'd see the same absolute improvement in latency. GNOME may also introduce its own undesirable variance, just like keyboard latency. I'd be very curious to see if those guesses holds up.
- KronisLV 3y ago> We all have different keyboards plugged into different USB interfaces plugged into different computers running different versions of different operating systems. I've actually been curious about getting a wireless keyboard recently, but wondered about how big of a latency impact there would be. Normally I use IDEs that definitely add a bit of sluggishness into the mix by themselves, but something compounded on top of that would probably make it way more annoying. A quick search lead me to this site: https://www.rtings.com/keyboard https://www.rtings.com/keyboard It does appear that they have a whole methodology for testing keyboards: https://www.rtings.com/keyboard/tests/latency https://www.rtings.com/keyboard/tests/latency For what it's worth, it seems that well made keyboards don't have too much latency to them, even when wireless (though the ones that use Bluetooth are noticeably worse): https://www.rtings.com/keyboard/1-3-1/graph/23182/single-key-latency-graph/razer-pro-type-ultra/29787 https://www.rtings.com/keyboard/1-3-1/graph/23182/single-key... Just found that interesting, felt like sharing. Might actually go for some wireless keyboard as my next one, if I find a good form factor. Unless that particular keyboard does something really well and most others just have way worse wireless hardware in them.
- DiabloD3 3y agoBTW, remember, most people still have 60hz monitors. Min latency can only be 16.6ms, and "fast as possible" is just going to vary inbetween 16.6 and 33.3ms. The real improvement wouldn't be reducing latency as much as allowing VRR signaling from windowed apps, it'd make the latency far more consistent.
- aidenn0 3y agoBest-case median latency @60hz is 8.3ms (i.e. if there were 0 time consumed by the input and render, it would vary equidistributed between 0 and 16.6ms.
- bobmcnamara 3y agoLinux, for better or for worse, doesn't have universal support for VSYNC. Without it, you can race the scanout and minimum latency can get well under 1ms. This was required for me to get a video stream down below 1 frame of latency.
- Qwertious 3y ago>BTW, remember, most people still have 60hz monitors. Min latency can only be 16.6ms, and "fast as possible" is just going to vary inbetween 16.6 and 33.3ms. No the minimum will be 0ms, since if the signal arrives just before the monitor refreshes then it doesn't need to wait. This is why people disable VSync/FPS caps in videogames - because rendering at higher than <60FPS> means that the latest frame is more up-to-date when the <60Hz> monitor refreshes. The maximum monitor-induced latency would be 16.6ms. Which puts the average at 8.3ms. Again, not counting CPU/GPU latency. 33.3ms would be waiting about two frames, which makes no sense unless there's a rendering delay.
- DiabloD3 3y agoThe article is about testing actual user experienced latency, and Mutter still buffers 1 frame. Actual observed latency is going to be between 16.6ms and 33.3ms before the user can see anything hit their eyeballs.
- gigatexal 3y agoThen use the Apple 2e and forgo all the nicities of modern operating systems. Honestly this take is a whole lot of words to shit on all the open source devs working hard to provide things to us for free and I’m not having it.
- refulgentis 3y ago+100. It's my least favorite talking point because I'm old enough to seen it linked 100 times, I find it very unlikely it was faster when measured by the same methods, and the article itself notes the funny math around CRTs.
- hulitu 3y agoOr even better: don't use Gnome. /s
- p9fus 3y ago[flagged]
- addicted 3y agoSuch a disappointing but typical HN comment. The changes described in the OP are unequivocally good. But the most promoted comment is obviously something snarky complaining about a tangential issue and not the actual thing the article’s about.
- pcwalton 3y agoWell, the Apple II had a 280x192 display (53 kpixel), and my current resolution (which is LoDPI!) is 2560x1600 (4 Mpixel). When you phrase it as "in 2024 we can render 76x the pixels with the same speed" it actually sounds rather impressive :)
- seba_dos1 3y ago> so there are many differences Yeah, one of those is that modern stacks often deliberately introduce additional latency in order to tackle some problems that Apple IIe did not really have to care about. Bringing power consumption down, less jitter, better hardware utilization and not having visual tearing tend to be much more beneficial to the modern user than minimizing input-to-display latency, so display pipelines that minimize latency are usually only used in a tiny minority of special use-cases, such as specific genres of video games. It's like complaining about audio buffer latency when compared to driving a 1-bit beeper.