11 ms·
Terminal latency (2017)
- nxrabl 8y ago(2017) Previous discussion: https://news.ycombinator.com/item?id=14798211 https://news.ycombinator.com/item?id=14798211
- sevensor 8y agoI'd love to see a followup study. GPU based terminal emulators (alacritty, kitty) have evolved a lot over the last two years.
- llimllib 8y agoiTerm is a GPU based terminal emulator now too, as long as the metal backend is active
- swiley 8y agoMy personal experience with GPU accelerated GUIs is that latency is always worse. Drawing text is something that the cpu is pretty good at and the GPU just means more back and forth over the buss, more driver coupling, more weird libraries.
- sevensor 8y agoThat would be my concern. But there are so many factors, I'd like to see some scientific measurement.
- 1996 8y agoMatches user reports like https://stackoverflow.com/questions/42888024/git-bash-mintty-is-extremely-slow-on-windows-10-os https://stackoverflow.com/questions/42888024/git-bash-mintty...
- raphlinus 8y agoI think you're right about GPU tending to have worse latency, but I think it's because that's the way the swap chain is set up and the use of blocking present calls. I've been studying this and am pretty sure I know how to make low latency on Windows work, mostly it's following the advice in [1]. If you do it right, then on modern hardware, DirectFlip kicks in and that saves you an additional frame that would ordinarily be eaten by the compositor. I plan to measure this at some point in the not too distant future, or would be happy to mentor somebody interested in taking it on. [1]: https://devblogs.microsoft.com/directx/dxgi-flip-model/ https://devblogs.microsoft.com/directx/dxgi-flip-model/
- mpweiher 8y agoAFAIK, GPUs are throughput devices, not latency-reducing devices. Happy to be proven wrong!
- deleted 8y ago[deleted]
- c_r_w 8y agoThanks, I knew I had seen this before but unbelievably there is no date on that article.
- dang 8y agoSubmissions on HN only get dated when they are aren't from the current year. That one was.
- snazz 8y agoConsidering its simplicity, I wonder why st fared so poorly. Also, I’m surprised that eshell did well on the latency part, since it sometimes feels laggy (which could be due to its reimplementation of basic Unix tools in elisp).
- data_block 8y agoIt's quite fast when you are not on macOS :^)
- bitwize 8y agoEeeeeuuugghh... desktop Linux.
- yellowapple 8y agoThe feeling is mutual, I'm sure.
- jcelerier 8y ago> Considering its simplicity, I wonder why st fared so poorly. I don't understand why in earth you would expect simple solutions to be fast. Most very fast software need some level of complexity in order to special-case for the fast platform primitives. See for instance glibc which is not simple when compared to musl but also rolls over it in benchmarks, because it uses many state of the art algorithms and many architecture-specific optimizations.
- tngranados 8y agoI think he means that st is simple regarding its features not its implementation (which I know nothing about).
- WalterGR 8y agoI don't understand why in earth you would expect That’s unnecessarily aggressive.
- 8y ago
- dmitriid 8y agoThrow in things like text/syntax highlighting, autocomplete, search etc., and 100ms latency will be a dream (speaking as oh-my-zsh user). Also: fancy fonts and ligatures
- nickjj 8y agoToo bad they didn't measure xterm. That one has always felt the best to me on a native Linux system by a large margin. Also Microsft's default WSL terminal (ubuntu.exe if you happen to be running Ubuntu WSL) is a lot faster than anything else I tried on Windows. I suppose that's what you get for using a low level UI API that's optimized for performance. Its input latency is lower than any other app on Windows. Back in December I did a Windows terminal review at: https://nickjanetakis.com/blog/conemu-vs-hyper-vs-terminus-vs-mobaxterm-terminator-vs-ubuntu-wsl https://nickjanetakis.com/blog/conemu-vs-hyper-vs-terminus-v... There's no scientific measurements on input latency but input latency is something I pay a lot of attention to, especially considering all you do is type into a terminal. It is the most important thing IMO. The TL;DR is the default WSL terminal is a lot better than anything else for low latency, but WSLtty is what I use personally due to it being more configurable while still being OK'ish for latency. Hyper and Terminus were the 2 worst performing terminals in both input latency and having UI bugs that made the terminal unusable for day to day usage (both Electron apps).
- andyjpb 8y agoHe was on MacOS so unfortunately couldn't do xterm. They do uxterm (which is a wrapper around xterm to put it into UTF-8 mode) here. https://lwn.net/Articles/751763/ https://lwn.net/Articles/751763/ TL;DR: This quote sums it up: "The first thing that struck me is that old programs like xterm and mlterm have the best response time, having worse case latency (2.4ms) better than the best case for all other terminals (10.6ms for st)."
- nickjj 8y agoThanks for the link. Glad to see the numbers back up exactly what I felt. I remember trying xterm, st and gnome terminal and gnome terminal was really bad. It felt comparable or maybe even worse than hyper. I also remember thinking "for such a less bloated terminal, st sure doesn't feel minimal". There was this level of latency present on st that xterm doesn't have. xterm with tmux in my opinion is the ultimate combo. You get a lightning fast terminal and all of the features you could ever want (windows, panes, searching, etc.). With a bit of configuring, xterm can do all sorts of nice things like having clickable URLs, customized keybinds, font adjustment, etc.. Plus you can make it look good.
- romwell 8y agoAs a keyboard player, I can tell you that anything over 10ms latency noticeably degrades the experience. 100ms of keypress-to-sound latency makes the instrument unplayable. Your ears will detect very small latencies; offset something just by 1-2ms, and you get an echo feel; 50ms will be off-beat. (Organ players have to deal with that kind of latency on their instrument[1], but it's a hard skill to learn, and limits the music that can be performed on the instrument. Say, following a drummer is out of the question.) Why people tolerate huge amounts of unnecessary latency is beyond me. And everything is laggy these days. Except MIDI/audio setups, that is. And even in that scene, Android got a low-latency API only last year. I say, the decade of 2020 will be not about increasing performance, but decreasing the goddamn latency down to unnoticeable levels. Or I really hope so. [1]https://music.stackexchange.com/questions/30454/how-does-a-pipe-organist-deal-with-latency-or-delay https://music.stackexchange.com/questions/30454/how-does-a-p...
- musicale 8y agoLife can be rough for bass players, given the wavelength and speed of sound - you have to play ahead of the beat just for a note to show up on time! ;-) 10ms of added latency is very irritating - even adding 4ms feels clunky on guitar/headphones and that's typical for playing through a DAW and digital effects. As much as I like the iPad ... drawing on it is still like drawing underwater, and touch-to-sound latency is still too high in many cases. On the other hand... I can almost tolerate a bit of latency playing a weighted keyboard because I imagine that a hammer is hitting a string so I adjust my playing accordingly. The keyboard also seems to trigger before the note bottoms out, which helps a bit (except when you're playing very quietly.) There was a terrible idea in the CRT era that when a user clicked on a menu you could do all sorts of computation to update menu contents and still have time to draw the menu before the next ~80Hz refresh. Even if you missed a frame "humans couldn't notice it." Unfortunately this failed horribly in practice because it frequently pushed things over the edge, resulting in two frames of latency (or many more if latency wasn't managed well) which made things feel sluggish and unresponsive. Even in 2019, though we have 120+ Hz user interfaces, asynchronous refresh, multi-gigahertz processors, and insane GPUs, menus are still clunky. Every time I click on a menu in macOS (Safari, for example, which I am using as I write this) I can almost hear it go "kachunk." Not even 10ms. ;-( Maybe the delay is an intentional fade-in or ... something, but I still hate it. Moral of the story: 10ms is terrible, and every bit of delay you add to a UI can push it (and your users) closer to the edge.
- macbookcabler 8y agoIt would be interesting to see an updated test. Since this report, multiple apps have undergone speed overhauls. The latest version of Hyper, for example, dropped DOM rendering in favor of Canvas/WebGL. That being said, there is a major difference in perceived speed working with terminals over a GUI like in macOS versus something with fewer layers. I hooked up a Raspberry Pi to do some vim editing using Raspbian Stretch Lite and it felt like editing on a supercomputer (right up until I needed to compile something).
- matt4077 8y agoThe only time I ever noticed a difference in input lag was when I had to fumble my way through the UEFI console. I had no idea what I was doing, but the speed was eerie.
- dfox 8y agoThis is common for anything that emulates text terminal on highres-ish graphical mode using common denominator VGA/VESA interfaces without any HW acceleration whatsoever (and also often with banked framebuffer). By the way, on 4k monitor you can discern that grub2 draws its menu from bottom up as it takes second or so. Linux FB console is significantly faster but still scrolling (ie. fullscreen redraw) is noticeably CPU intensive.
- OJFord 8y agoYep, and alacritty now _does_ support scrolling (was only available on a branch at the time of the post, so tmux used).
- mrob 8y agolibvte is a major offender here. It's used in several popular terminal emulators, and it's deliberately capped at approximately 40fps[0], which means on a 60Hz display you'll sometimes get an additional frame of latency, and not even predictably because the timing is so uneven. Set your keyboard autorepeat to 60Hz, hold down a key in a libvte-based terminal, and watch how bad it is. Now try again with xterm and see what it's supposed to be like. I can only assume the slow update is some misguided attempt at power saving. [0] https://github.com/GNOME/vte/blob/master/src/vte.cc#L10547 https://github.com/GNOME/vte/blob/master/src/vte.cc#L10547
- swiley 8y agoPeople keep knocking xterm but honestly it still is probably the best and most complete terminal emulator.
- nickjj 8y agoIt is absolutely my favorite my terminal. I'm happy to see it's still being actively developed.
- snazz 8y agoIt also has the awesome Secure Keyboard feature, which I haven’t yet seen anywhere else.
- lelf 8y agoMacOS Terminal.app
- AnIdiotOnTheNet 8y agoYou know, just today I had to install Xterm on my Lubuntu box because the DosBOX debugger is completely mangled by LXTerminal. LXTerminal doesn't get all the blame though, DOSBox devs should know better than to use a terminal emulator (with all its in-band signaling fail) and instead create a new non-terminal console window. It's not like they don't already have the code for one just lying around.
- 8y ago
- mikepurvis 8y agoCan confirm that latency on iTerm2 is awful. I tried it for a while at the behest of a colleague and switched back to Terminal.app because I couldn't bear the lag.
- tomsmeding 8y agoHow long ago did you test that? I recall trying out iTerm2 some time ago and being appalled at the latency as well, but fairly recently I reconsidered it and found it to be more than quick enough for my needs.
- mikepurvis 8y agoAt least a year ago, but my recollection is that it was context-dependent too. Like, sometimes it was fine, and other times it wasn't, but it wasn't really clear to me what caused the problem (wasn't obvious things like low memory or having a giant scrollback).
- sagebird 8y agoI am curious how hn would construct a program which tried to minimize the latency of "simplest" test possible. Lets say -- press the space bar and the pixel at top right of screen turns green. I used to use nasm on a dos machine - where it was possible to write a rather straightforward assembly program that would take a keypress and update a pixel -- but I am not sure how abstract/layered graphics stacks are on operating systems these days -- IE -- what is the simplest/low latency method to tell a computer to flip an pixel? SDL?
- nickjj 8y agoA few months ago I asked the MS devs why their default WSL terminal felt incredibly responsive and they replied with a ton of details. You can read the thread here: https://github.com/Microsoft/console/issues/327 https://github.com/Microsoft/console/issues/327
- cschep 8y agoWow this is really wonderful! Thanks for spawning that thread into existence and posting it here :)
- deleted 8y ago[deleted]
- Dahoon 8y agoWhile the reply is great I feel it is missing the point a bit. The reason it feels so fast is IMO because everything else is so slow. Look at the numbers in below link (near the bottom). Windows 10 is extremely slow. Linux is often twice as fast with the same hardware and the same software. Why they still haven't fixed it is beyond me. EDIT. Doh, forgot the link. http://isitsnappy.com/ http://isitsnappy.com/
- nickjj 8y ago> Linux is often twice as fast with the same hardware and the same software. Why they still haven't fixed it is beyond me. Linux is no different. Gnome terminal has a ton of input latency compared to xterm. It's like night and day. A lot of graphical apps in Linux have added input latency just like Windows. It's due to layers of UI abstractions and frameworks (the same as Windows but different UI toolkits of course). That links just shows that VSCode and Atom are both horrendously bad for input latency on any OS.
- mruts 8y agoWhy is xterm not included? It’s probably the most popular terminal on Linux. It’s also noticeably laggy. I’m surprised that eshell performance is so good. Maybe because it supports less features than a standard terminal? I use Emacs and Elisp everyday and both are dog slow. It’s unfortunate that they still haven’t managed to replace the interpreter and bytecode compiler with a faster scheme compiler after all this time. As an aside, GNU projects seem broken in their management. Every project seems to be run by some get off my lawn egomaniac. (ex RMS, Ulrich Drepper)
- stonogo 8y ago> Why is xterm not included? Because it doesn't run on a Mac. It was tested elsewhere though and found to be among the quickest, so maybe your configuration is suboptimal. > Every project seems to be run by some get off my lawn egomaniac. (ex RMS, Ulrich Drepper) The list of projects currently run by that list of people comprises "emacs and nothing else." Drepper left glibc maintainership many years ago and RMS has not been actively involved in anything other than emacs for a similar duration (aside from crippling gcc backend splitting).
- yellowapple 8y agoDoesn't X11 ship with macOS (i.e. to run "legacy" Unix apps)? I could've sworn I've used xterm before on it.
- 0x0 8y agoDoesn't XQuartz come with xterm?
- gnachman 8y agoAs mentioned, this is somewhat out of date. iTerm2 has gotten a GPU renderer since then, which should reduce the latency. Unfortunately I can't get typometer to work. I guess it's because it's not requesting the right permissions on macOS 10.14.
- acdha 8y agoIf you have an iPhone, http://isitsnappy.com/ http://isitsnappy.com/ is very easy to test with
- ksec 8y agoiPhone 6s Touch Screen had ~40ms end to end latency, it was good but wished it was better.* The iPhone XS had about 40 as well, but the iPhone XR had 60ms+ and in some case closing in to 80ms. ( It was 60ms + 10+ from Display if I remember correctly ) I know it is a hard to sell "figure", but I wish Apple could find a way to market this, and improve on it. The Apple Pencil 2 and Pro Motion, are still no where close to real time. It still feels lag, or Jank. Note: I try to Google for the source but unfortunately nothing came up. Edit: The only thing I got was this Chinese Site with a Table of input latency. http://bbs.nga.cn/read.php?tid=16347225&page=1 http://bbs.nga.cn/read.php?tid=16347225&page=1
- nickpsecurity 8y ago"I know it is a hard to sell "figure", but I wish Apple could find a way to market this" Blackberry did that with the Playbook pitting it against iPads. They showed it was more responsive by having a video game, a browser, and other stuff running with no lag. Apple could similarly highlight faster response time.
- esaym 8y agoI've used KDE's Konsole for 20+ years. How would I got about testing its latency??
- mirimir 8y agoI spend lots of time on remote servers and VPS with ssh via Tor. So I'm used to ~500 msec latency. But hitting VirtualBox VMs via VRDP via Tor, that can bring me to tears. Installing Debian, say, is fine. Then you try to login. debian login: uuuss debian login: usssss debian login: uuus And if you get to password, it's far worse, because you can't see what you've typed. So I'd set user as "x" and its password as "z". And once I'd logged in, do: setterm -repeat off setterm -repeat off >> /etc/issue But then there's the joy of using GUIs. Mouse pointers with ~500 msec or more latency are crazy making.