5 ms·

Terminal Latency (2017)

66 points by merwanedr 4y ago

tingletech 4y ago
I learned vi over dial up in the early 90s. One's fingers would often be very far ahead of the screen.
- latchkey 4y ago
  Those terminals were a huge upgrade over the 300-1200 baud modem connections in the 80s...
  - tingletech 4y ago
    At one job I had in 95, a few times I did connect at 300. (I'd hang up and try again if that happened, but sometimes I would vi at 1200 baud. 2400 I think was normal, and sometimes I'd get lucky and connect at 48k. It was nominally at 56k modem, but I never saw in connect at that.) I can't remember the name of the terminal emulator I used from windows in 95, or what even the browser was, must have been mosaic? I was coding up web pages for lawyers at https://www.lawinfo.com https://www.lawinfo.com / experienced attorneys referral service before Guenter sold it to Thompson Reuters. Pre-web, the outfit would place ads in yellow pages nationally, and then transfer calls to attorneys who subscribed. I supported the computers for the folks who took the calls from the yellow page ads, and the computers for the folks who cold called attorneys all day, but most of the day I was creating HTML in vi for lawyers. I think we used something called lantastic; and we had a commercial CRM system that ran on DOS and dialed the phones for the sales team... it's on the tip of my tongue... I remember loading new phone numbers into it from some vendor feed for the sales force. We were in a weird strip mall in Encinitas, and I remember hanging out with the folks who worked next door at some sort of computer business that made our PCs but also worked on some sort of B2B software.
- icedchai 4y ago
  Could you type at 2400 baud? I upgraded to a 9600 baud modem in 1992, I think. That was finally when things felt "fast."
  - tingletech 4y ago
    No, but I can read at 300 baud iirc.
    - icedchai 4y ago
      Nobody was using 300 baud in the 90's! Maybe that's why I was confused.
      - tingletech 4y ago
        modems in the 90s would still negotiate 300 baud connections depending on how good the phone connection was, which could depend on the weather. I think there also needs to be a full duplex loop from the terminal emulator to the unix host and back for the character to show up on the screen. And consider that the both the PC that the emulator was running on was a 90s PC, and the web server I think was a shared host at the ISP. Some vi commands also would trigger a lot of screen update action. It was very easy to type far ahead of what was on the screen. If I lost track of what I had typed, I would have to stand up and walk away from the keyboard for a sec to let the screen catch up.
        icedchai 4y ago
        I started using modems in the late 80's. My first one was 1200 baud. Never once did a modem negotiate 300 baud on its own, even in the worst conditions. Were you connecting through a tin-can with string? Terminal emulators are not CPU intensive applications. I ran one on an Apple II (8-bit, 1 mhz) and it could keep up with at least 2400 baud. If you were refreshing the screen with vi, I could see it being slow.
        tingletech 4y ago
        I was mostly inserting tags at the start and end of paragraphs of with `I` and `A` and other repetitive markup where I might have to `I` and the down arrow three times and then something else. I'd also do a lot of `:` ex based search and replace. The way the university dial up pool worked, and when I worked for an ISP for 6 weeks in 96, there would be a room full of phone lines and modems where the dial in would happen. Sometime you would get one bad line, and sometimes you would get one bad modem, and probably sometimes you would get a bad line going to a bad modem. To keep users from paying local tolls, you would have to have several locations for the modem pools. In the case of the ISP, Bill Blue rented garages around the county and had T1s or something run out the the garages. I didn't say it was common to connect at 300 baud, or that the vi story had anything to do with 300 baud. I know I did connect at 300 baud more than once in the early 90s, and I that is when I found out that I could read usenet news at 300 baud w/o using a pager.
dang 4y ago
Related: Terminal latency (2017) - https://news.ycombinator.com/item?id=19443076 https://news.ycombinator.com/item?id=19443076 - March 2019 (109 comments) Terminal and shell performance - https://news.ycombinator.com/item?id=14798211 https://news.ycombinator.com/item?id=14798211 - July 2017 (204 comments)
leephillips 4y ago
Maybe of more interest would be https://lwn.net/Articles/751763/ https://lwn.net/Articles/751763/, which measures latency on Linux.
terminallybored 4y ago
The zutty project had an interesting article on terminal latency, as well: https://tomscii.sig7.se/2021/01/Typing-latency-of-Zutty https://tomscii.sig7.se/2021/01/Typing-latency-of-Zutty
bitwize 4y ago
Curiously not listed: xterm, which has close to the lowest latency of any open source TE. But who uses that anymore?
- spc476 4y ago
  I still do. Been using it for over 30 years now.
- ac130kz 4y ago
  I did, I switched to kitty, because of Wayland. It feels crazy responsive even without looking at tests
- teddyh 4y ago
  I tried to switch from XTerm to GNOME Terminal. It went well for a while, and better Unicode and emoji display was nice, but then a new version of GNOME Terminal came out which broke the ability to use the Meta keys for sending an ESC prefix; it is now hard-coded to only accept the Alt keys to do that. So I had to switch back to XTerm.
- mhd 4y ago
  I do, mostly. I often ran in some terminal emulation issues with other terminals, especially when using older software. These days, I could probably switch to another terminal, as I'm in tmux quite often, which creates those compatibility issues itself, no matter what "backend" you're using.
  - bitwize 4y ago
    The developer of xterm actually maintains a battery of tests which exercise corner cases in the DEC VT protocol and ensure that xterm conforms in the manner that a real terminal would: https://invisible-island.net/vttest/vttest.html https://invisible-island.net/vttest/vttest.html Xterm really is a terminal emulator. Most other "modern" TEs are more like shitty xterm emulators.
    - mhd 4y ago
collegeburner 4y ago
semi related but anybody know how i fix the powershell latency on windows? it's literally unusable as a shell besides running scripts.
- LtdJorge 4y ago
  Are you using old PowerShell or the newer Open Source PowerShell 6/7? Try also running it from Terminal, the official modern terminal app from the store. It's much faster than bare cmd or PowerShell, IIRC it's because of conhost.
  - von_lohengramm 4y ago
    It is because of conhost. You can actually replace the default Windows one with the new OpenConsole and it makes your entire PC faster. Kinda neat.
    - thfuran 4y ago
      Wait, what?
      - vetinari 4y ago
        But only on Windows 11, unfortunately.
  - ajoseps 4y ago
    For me the new Terminal app is much slower than something like Cmder (ConEmu)
adrusi 4y ago
~2 msec (mouse) 8 msec (average time we wait for the input to be processed by the game) 16.6 (game simulation) 16.6 (rendering code) 16.6 (GPU is rendering the previous frame, current frame is cached) 16.6 (GPU rendering) 8 (average for missing the vsync) 16.6 (frame caching inside of the display) 16.6 (redrawing the frame) 5 (pixel switching) I'm not very familiar with graphics pipelines, but some stuff here seems wrong. If a game is rendering at 60fps, the combined compute time for simulation+rendering should be 16.6 ms. You can't start simulating the next tick while rendering the previous tick unless you try to do some kind of copy-on-write memory management for the entire game state. And with double buffering, the GPU should be writing frame n to the display cable at the same time as it's computing frame n+1., and the display writing the frame to its cache buffer should be happening at the same time as the GPU writes the frame to the cable. By my count that's a whole 50 ms that shouldn't be there. From the linked article: One thread is calculating the physics and logic for frame N while another thread is generating rendering commands based on the simulation results of frame N-1. Maybe modern games do use CoW memory? [The GPU] might collect all drawing commands for the whole frame and not start to render anything until all commands are present. It might, but is this typical behavior? This implies that the GPU would just sit idle if it finished rendering a frame before the CPU finished sending commands to draw the next one — why would it do that? Most monitors wait until a new frame was completely transferred before they start to display it adding another frame of latency. Maybe this is what is meant by the "16.6 (frame caching inside of the display)" item? That might be real then.
- amarshall 4y ago
  Input + display lag is a decent chunk of that, at least.
- alberth 4y ago
  John Carmack famously said: “I can send an IP packet to Europe faster than I can send a pixel to the screen. How f’d up is that?” https://mobile.twitter.com/id_aa_carmack/status/193480622533120001 https://mobile.twitter.com/id_aa_carmack/status/193480622533...
- sdwr 4y ago
modeless 4y ago
The bad news is the defaults on modern platforms are often very bad for latency. The good news is that it is possible to achieve good latency on most modern systems with a lot of attention to detail. With good hardware and good software it is even possible to e.g. run console emulators with lower latency than they would have on original hardware connected to a CRT. I just wrote a three part series detailing a lot of ways to improve latency: Intro: https://james.darpinian.com/blog/latency https://james.darpinian.com/blog/latency Techniques to improve latency in your applications: https://james.darpinian.com/blog/latency-techniques https://james.darpinian.com/blog/latency-techniques Platform-specific considerations: https://james.darpinian.com/blog/latency-platform-considerations https://james.darpinian.com/blog/latency-platform-considerat...
- ad8e 4y ago
  > Delay rendering until just before VSync: If you get it slightly wrong and your frame takes slightly more time to render than you thought, your frame may not be done in time for VSync. Then it will have to wait a whole extra frame and the previous frame will be displayed twice, causing a hitch in any animations. According to docs, there are extensions WGL_EXT_swap_control_tear/GLX_EXT_swap_control_tear [0], that cause late frames to tear instead of wait a full frame. They don't work on my machine (my Intel HD 4000 reports that it is supported and then silently fails), but this should be the ideal swap mechanism. [0]: https://registry.khronos.org/OpenGL/extensions/EXT/GLX_EXT_swap_control_tear.txt https://registry.khronos.org/OpenGL/extensions/EXT/GLX_EXT_s...
  - modeless 4y ago
    I discuss tearing here: https://james.darpinian.com/blog/latency-techniques#tearing-prevention https://james.darpinian.com/blog/latency-techniques#tearing-... and here https://james.darpinian.com/blog/latency-platform-considerations#directx https://james.darpinian.com/blog/latency-platform-considerat... Tearing is a pretty bad artifact so I wouldn't say that enabling it is ideal. I'm a stickler for low latency but even I don't think it's worth it in most cases. It's possible to achieve great latency without tearing. The ideal swap mechanism would be VRR when available. Those GL extensions likely predate modern composition window managers and fail to work when compositing is enabled. As I discuss in the platform specific considerations section, tearing on Windows requires either full screen, or Multiplane Overlay which is not supported by OpenGL.
dwheeler 4y ago
Related: "Why Modern Computers Struggle to Match the Input Latency of an Apple IIe" https://www.extremetech.com/computing/261148-modern-computers-struggle-match-input-latency-apple-iie https://www.extremetech.com/computing/261148-modern-computer... The Apple //e, with its 1MHz clock and 8-bit CPU, had an average latency from keypress to character display of 30msec. Modern computers are dramatically slower in keypress to text display. There are reasons, but end users see a slower system.
- fhars 4y ago
  Those results are actually by Dan Luu and done at about the same time (2017), too: https://danluu.com/input-lag/ https://danluu.com/input-lag/
aurelien 4y ago
why not xterm? xterm respect most of standard, maybe one of the closest to all standards.
kgwxd 4y ago
Not a big deal, 122.6 ms is still way below the Doherty Threshold :) Dropping into a real terminal on Linux feels so weird when typing. I swear sometimes I see a letter on the screen before I actually touch the key. Similar to playing an Atari on a CRT, paddle games, like Breakout, feel like you're physically attached to the on-screen paddle with a sturdy rod as opposed to the mushy feel you get from a mouse in modern games.

66 points by merwanedr 4y ago

tingletech 4y ago

I learned vi over dial up in the early 90s. One's fingers would often be very far ahead of the screen.

latchkey 4y ago
Those terminals were a huge upgrade over the 300-1200 baud modem connections in the 80s...
- tingletech 4y ago
  At one job I had in 95, a few times I did connect at 300. (I'd hang up and try again if that happened, but sometimes I would vi at 1200 baud. 2400 I think was normal, and sometimes I'd get lucky and connect at 48k. It was nominally at 56k modem, but I never saw in connect at that.) I can't remember the name of the terminal emulator I used from windows in 95, or what even the browser was, must have been mosaic? I was coding up web pages for lawyers at https://www.lawinfo.com https://www.lawinfo.com / experienced attorneys referral service before Guenter sold it to Thompson Reuters. Pre-web, the outfit would place ads in yellow pages nationally, and then transfer calls to attorneys who subscribed. I supported the computers for the folks who took the calls from the yellow page ads, and the computers for the folks who cold called attorneys all day, but most of the day I was creating HTML in vi for lawyers. I think we used something called lantastic; and we had a commercial CRM system that ran on DOS and dialed the phones for the sales team... it's on the tip of my tongue... I remember loading new phone numbers into it from some vendor feed for the sales force. We were in a weird strip mall in Encinitas, and I remember hanging out with the folks who worked next door at some sort of computer business that made our PCs but also worked on some sort of B2B software.
icedchai 4y ago
Could you type at 2400 baud? I upgraded to a 9600 baud modem in 1992, I think. That was finally when things felt "fast."
- tingletech 4y ago
  No, but I can read at 300 baud iirc.
  - icedchai 4y ago
    Nobody was using 300 baud in the 90's! Maybe that's why I was confused.
    - tingletech 4y ago
      modems in the 90s would still negotiate 300 baud connections depending on how good the phone connection was, which could depend on the weather. I think there also needs to be a full duplex loop from the terminal emulator to the unix host and back for the character to show up on the screen. And consider that the both the PC that the emulator was running on was a 90s PC, and the web server I think was a shared host at the ISP. Some vi commands also would trigger a lot of screen update action. It was very easy to type far ahead of what was on the screen. If I lost track of what I had typed, I would have to stand up and walk away from the keyboard for a sec to let the screen catch up.
      - icedchai 4y ago
        I started using modems in the late 80's. My first one was 1200 baud. Never once did a modem negotiate 300 baud on its own, even in the worst conditions. Were you connecting through a tin-can with string? Terminal emulators are not CPU intensive applications. I ran one on an Apple II (8-bit, 1 mhz) and it could keep up with at least 2400 baud. If you were refreshing the screen with vi, I could see it being slow.
        tingletech 4y ago
        I was mostly inserting tags at the start and end of paragraphs of with `I` and `A` and other repetitive markup where I might have to `I` and the down arrow three times and then something else. I'd also do a lot of `:` ex based search and replace. The way the university dial up pool worked, and when I worked for an ISP for 6 weeks in 96, there would be a room full of phone lines and modems where the dial in would happen. Sometime you would get one bad line, and sometimes you would get one bad modem, and probably sometimes you would get a bad line going to a bad modem. To keep users from paying local tolls, you would have to have several locations for the modem pools. In the case of the ISP, Bill Blue rented garages around the county and had T1s or something run out the the garages. I didn't say it was common to connect at 300 baud, or that the vi story had anything to do with 300 baud. I know I did connect at 300 baud more than once in the early 90s, and I that is when I found out that I could read usenet news at 300 baud w/o using a pager.

dang 4y ago

Related: Terminal latency (2017) - https://news.ycombinator.com/item?id=19443076 https://news.ycombinator.com/item?id=19443076 - March 2019 (109 comments) Terminal and shell performance - https://news.ycombinator.com/item?id=14798211 https://news.ycombinator.com/item?id=14798211 - July 2017 (204 comments)

leephillips 4y ago

Maybe of more interest would be https://lwn.net/Articles/751763/ https://lwn.net/Articles/751763/, which measures latency on Linux.

terminallybored 4y ago

The zutty project had an interesting article on terminal latency, as well: https://tomscii.sig7.se/2021/01/Typing-latency-of-Zutty https://tomscii.sig7.se/2021/01/Typing-latency-of-Zutty

bitwize 4y ago

Curiously not listed: xterm, which has close to the lowest latency of any open source TE. But who uses that anymore?

spc476 4y ago
I still do. Been using it for over 30 years now.
ac130kz 4y ago
I did, I switched to kitty, because of Wayland. It feels crazy responsive even without looking at tests
teddyh 4y ago
I tried to switch from XTerm to GNOME Terminal. It went well for a while, and better Unicode and emoji display was nice, but then a new version of GNOME Terminal came out which broke the ability to use the Meta keys for sending an ESC prefix; it is now hard-coded to only accept the Alt keys to do that. So I had to switch back to XTerm.
mhd 4y ago
I do, mostly. I often ran in some terminal emulation issues with other terminals, especially when using older software. These days, I could probably switch to another terminal, as I'm in tmux quite often, which creates those compatibility issues itself, no matter what "backend" you're using.
- bitwize 4y ago
  The developer of xterm actually maintains a battery of tests which exercise corner cases in the DEC VT protocol and ensure that xterm conforms in the manner that a real terminal would: https://invisible-island.net/vttest/vttest.html https://invisible-island.net/vttest/vttest.html Xterm really is a terminal emulator. Most other "modern" TEs are more like shitty xterm emulators.
  - mhd 4y ago

collegeburner 4y ago

semi related but anybody know how i fix the powershell latency on windows? it's literally unusable as a shell besides running scripts.

LtdJorge 4y ago
Are you using old PowerShell or the newer Open Source PowerShell 6/7? Try also running it from Terminal, the official modern terminal app from the store. It's much faster than bare cmd or PowerShell, IIRC it's because of conhost.
- von_lohengramm 4y ago
  It is because of conhost. You can actually replace the default Windows one with the new OpenConsole and it makes your entire PC faster. Kinda neat.
  - thfuran 4y ago
    Wait, what?
    - vetinari 4y ago
      But only on Windows 11, unfortunately.
- ajoseps 4y ago
  For me the new Terminal app is much slower than something like Cmder (ConEmu)

adrusi 4y ago

~2 msec (mouse) 8 msec (average time we wait for the input to be processed by the game) 16.6 (game simulation) 16.6 (rendering code) 16.6 (GPU is rendering the previous frame, current frame is cached) 16.6 (GPU rendering) 8 (average for missing the vsync) 16.6 (frame caching inside of the display) 16.6 (redrawing the frame) 5 (pixel switching) I'm not very familiar with graphics pipelines, but some stuff here seems wrong. If a game is rendering at 60fps, the combined compute time for simulation+rendering should be 16.6 ms. You can't start simulating the next tick while rendering the previous tick unless you try to do some kind of copy-on-write memory management for the entire game state. And with double buffering, the GPU should be writing frame n to the display cable at the same time as it's computing frame n+1., and the display writing the frame to its cache buffer should be happening at the same time as the GPU writes the frame to the cable. By my count that's a whole 50 ms that shouldn't be there. From the linked article: One thread is calculating the physics and logic for frame N while another thread is generating rendering commands based on the simulation results of frame N-1. Maybe modern games do use CoW memory? [The GPU] might collect all drawing commands for the whole frame and not start to render anything until all commands are present. It might, but is this typical behavior? This implies that the GPU would just sit idle if it finished rendering a frame before the CPU finished sending commands to draw the next one — why would it do that? Most monitors wait until a new frame was completely transferred before they start to display it adding another frame of latency. Maybe this is what is meant by the "16.6 (frame caching inside of the display)" item? That might be real then.

amarshall 4y ago
Input + display lag is a decent chunk of that, at least.
alberth 4y ago
John Carmack famously said: “I can send an IP packet to Europe faster than I can send a pixel to the screen. How f’d up is that?” https://mobile.twitter.com/id_aa_carmack/status/193480622533120001 https://mobile.twitter.com/id_aa_carmack/status/193480622533...
sdwr 4y ago

modeless 4y ago

The bad news is the defaults on modern platforms are often very bad for latency. The good news is that it is possible to achieve good latency on most modern systems with a lot of attention to detail. With good hardware and good software it is even possible to e.g. run console emulators with lower latency than they would have on original hardware connected to a CRT. I just wrote a three part series detailing a lot of ways to improve latency: Intro: https://james.darpinian.com/blog/latency https://james.darpinian.com/blog/latency Techniques to improve latency in your applications: https://james.darpinian.com/blog/latency-techniques https://james.darpinian.com/blog/latency-techniques Platform-specific considerations: https://james.darpinian.com/blog/latency-platform-considerations https://james.darpinian.com/blog/latency-platform-considerat...

ad8e 4y ago
> Delay rendering until just before VSync: If you get it slightly wrong and your frame takes slightly more time to render than you thought, your frame may not be done in time for VSync. Then it will have to wait a whole extra frame and the previous frame will be displayed twice, causing a hitch in any animations. According to docs, there are extensions WGL_EXT_swap_control_tear/GLX_EXT_swap_control_tear [0], that cause late frames to tear instead of wait a full frame. They don't work on my machine (my Intel HD 4000 reports that it is supported and then silently fails), but this should be the ideal swap mechanism. [0]: https://registry.khronos.org/OpenGL/extensions/EXT/GLX_EXT_swap_control_tear.txt https://registry.khronos.org/OpenGL/extensions/EXT/GLX_EXT_s...
- modeless 4y ago
  I discuss tearing here: https://james.darpinian.com/blog/latency-techniques#tearing-prevention https://james.darpinian.com/blog/latency-techniques#tearing-... and here https://james.darpinian.com/blog/latency-platform-considerations#directx https://james.darpinian.com/blog/latency-platform-considerat... Tearing is a pretty bad artifact so I wouldn't say that enabling it is ideal. I'm a stickler for low latency but even I don't think it's worth it in most cases. It's possible to achieve great latency without tearing. The ideal swap mechanism would be VRR when available. Those GL extensions likely predate modern composition window managers and fail to work when compositing is enabled. As I discuss in the platform specific considerations section, tearing on Windows requires either full screen, or Multiplane Overlay which is not supported by OpenGL.

dwheeler 4y ago

Related: "Why Modern Computers Struggle to Match the Input Latency of an Apple IIe" https://www.extremetech.com/computing/261148-modern-computers-struggle-match-input-latency-apple-iie https://www.extremetech.com/computing/261148-modern-computer... The Apple //e, with its 1MHz clock and 8-bit CPU, had an average latency from keypress to character display of 30msec. Modern computers are dramatically slower in keypress to text display. There are reasons, but end users see a slower system.

fhars 4y ago
Those results are actually by Dan Luu and done at about the same time (2017), too: https://danluu.com/input-lag/ https://danluu.com/input-lag/

aurelien 4y ago

why not xterm? xterm respect most of standard, maybe one of the closest to all standards.

kgwxd 4y ago

Not a big deal, 122.6 ms is still way below the Doherty Threshold :) Dropping into a real terminal on Linux feels so weird when typing. I swear sometimes I see a letter on the screen before I actually touch the key. Similar to playing an Atari on a CRT, paddle games, like Breakout, feel like you're physically attached to the on-screen paddle with a sturdy rod as opposed to the mushy feel you get from a mouse in modern games.