4 ms·

the most common terminal benchmark I see cited (by at least two orders of magnitude) is the rate at which a terminal can display output, often measured by runni

the most common terminal benchmark I see cited (by at least two orders of magnitude) is the rate at which a terminal can display output, often measured by running cat on a large file. This is pretty much as useless a benchmark as I can think of It's a really helpful benchmark, IMO, as it's the main problem I see with different terminals. On a chromebook, most SSH clients are effectively useless because if you accidentally run a command that prints a lot of output (even just 'dmesg'), the terminal locks up for a huge amount of time, seconds or even minutes. You can't even interrupt the output quickly. I appreciate that it's a different problem to the latency that the OP is trying to measure, but as a benchmark, it's actually very useful.

blattimwind 9y ago
TFA > The closest thing that I care about is the speed at which I can ^C a command when I’ve accidentally output too much to stdout, but as we’ll see when we look at actual measurements, a terminal’s ability to absorb a lot of input to stdout is only weakly related to its responsiveness to ^C.
btilly 9y ago
Later in the same paragraph he addresses your exact problem, and points out that the speed of quitting a command that prints too much output is poorly correlated with the speed of spewing output. Given how easy it is to accidentally spew something that I don't want to wait for, even if it is spewing quickly, I'm squarely with him in not caring about the speed of display. Slow it down to just faster than my eyes can make sense of it, and make ^C fast, and my life will be better.
- deleted 9y ago
  [deleted]
- VintageCool 9y ago
  Can we create a metric specifically for that? when SSHed into a remote machine, if I run a command that spews a lot of text, how quickly does the terminal respond to ^C, stop printing text, and return me to the prompt.
- joosters 9y ago
  In my experience, the speed of a terminal responding to a ^C is highly correlated with the speed of its output. It's true that there's no need for a slow rendering terminal to also be slow at reacting to ^C, but it always tends to be the slow terminals that jam up. I agree totally with the speed of display updates not really being important - if my terminal is spewing hundreds of pages of text, it doesn't matter whether it's redrawing at 50fps or 5fps. My hunch is that the slowest terminals are the ones that insist upon drawing every single character of output. They then end up with a huge buffer of text that needs to be rendered even though the ^C may have been sent and the noisy program has been terminated.
  - btilly 9y ago
    The author of the article just benchmarked a bunch of performance stuff about terminals under different conditions. He said that in his benchmarks they are not well correlated and gave a specific terminal which specifically demonstrates it. I trust the author's benchmarks over your experience. (Doubly so since my experience matches the author's.)
- Tyriar 9y ago
  I looked into this quite a bit when I was optimizing xterm.js. Based on my findings, ^C is highly related to the speed of the output because the process running in the shell may be way ahead of the terminal's parsing/rendering. Imagine you run `cat foo`, the shell could take around 1s to send the output over to the terminal, the terminal might then take 10 seconds to parse and render the output. So after 1 second a ^C will actually do nothing because the cat call has finished. This is the case with Hyper, it hangs due to slow parsing and too much DOM interaction (as hterm was not designed for this sort of thing). There's actually a mechanism for telling the process to pause and resume (sending XOFF/XON signals), which allows the terminal and shell to stay completely in sync (^C very responsive). However, these only really work well in bash as oh-my-zsh for example overrides the signal with a custom keybinding. Related links: Original PR: https://github.com/sourcelair/xterm.js/pull/447 https://github.com/sourcelair/xterm.js/pull/447 Post-PR bug: https://github.com/sourcelair/xterm.js/issues/511 https://github.com/sourcelair/xterm.js/issues/511
  - btilly 9y ago
    Well, given that I mostly use the default shell for my system, which tends to be bash, I prefer shells that send XOFF/XON signals. And now I can pick a very responsive terminal over a fast rendering one. :-) If this becomes popular enough, then zsh will figure out how to offer the feature that bash already does, and terminals will happily adopt it. Then everyone's lives are better! :-)
  - scottlamb 9y ago
    If the sending process blocks after filling the pipe (on Linux, 512 bytes), hitting ctrl-C should be effective—any of these terminals should be able to sink that in negligible time. If it instead takes a long time, there are probably large buffers between: * If you're talking about ssh to a faraway machine, the TCP layer is probably responsible. (I'm not even sure if there's anything you can do about this; the buffer (aka "window size" in TCP terminology, plus the send and receive buffers on their respective ends) is meant to be at least the bandwidth-delay product, and as far as I know, the OS doesn't provide an interface to tell it you don't need a lot of bandwidth for this connection. It'd be nice if you could limit the TCP connection's bandwidth to what the terminal could sink.) * If you're talking about something running on the machine itself, it's probably an over-large buffer inside the terminal program itself.
kps 9y ago
That's what 'stty discard' was for, but apparently Linux doesn't implement it.
- spudlyo 9y ago
  Reminds me of my 300/1200 baud days, when you couldn't live without it.
glangdale 9y ago
This might be a dumb question, but why do terminals spew output anyhow? Past a certain point it's clearly unreadable. Once the terminal starts getting behind this is a UI failure IMO. So why not (say) buffer it up somewhere, show a preview, show a "I would be spewing output right now, press <Space> to see what the last screen is, press Ctrl-C to stop, press 's' to just spew output". The speeds and amounts of data for which this happens could be completely configurable. You can always put a limit on how much to buffer up (I'm not saying that this system should completely buffer output files until you run out of disk space), and sometimes 'spewing' is actually what we want.
- cat199 9y ago
  Hardware terminals had this feature, ish. The vt220 had a 'slow scroll' speed which would buffer text and scroll it at a viewable speed, limited by the quite small memory on the screen. It also had a 'pause' key which would pause the display and then continue the output (again limited by the terminal's memory). See also PC 'scroll lock' key.
- dredmorbius 9y ago
  Not a dumb question at all. Various tools can and do deal with the spew though. Ofhand, script (typescript), screen, and tmux. If you're running a session through a serial terminal emulator (e.g., minicom), that would be another instance. I'm not going to claim these are particularly mainstream uses (though I've made use of each of them, and been grateful for the ability to do so). But they do exist, and I suspect there are others.
- JdeBP 9y ago
  You might want to read up on the design of mosh. The way to tackle this is not to "buffer output up". In fact, the way to tackle this is the opposite of filling up buffers with output. It is to decouple the terminal emulation from the rendering. Mosh runs the terminal emulator on the remote server machine, and transmits snapshots of state (using a difference algorithm for efficiency) at regular intervals over the network to the client, which renders the terminal state snapshots to the display on the local client.

blattimwind 9y ago

TFA > The closest thing that I care about is the speed at which I can ^C a command when I’ve accidentally output too much to stdout, but as we’ll see when we look at actual measurements, a terminal’s ability to absorb a lot of input to stdout is only weakly related to its responsiveness to ^C.

btilly 9y ago

Later in the same paragraph he addresses your exact problem, and points out that the speed of quitting a command that prints too much output is poorly correlated with the speed of spewing output. Given how easy it is to accidentally spew something that I don't want to wait for, even if it is spewing quickly, I'm squarely with him in not caring about the speed of display. Slow it down to just faster than my eyes can make sense of it, and make ^C fast, and my life will be better.

deleted 9y ago
[deleted]
VintageCool 9y ago
Can we create a metric specifically for that? when SSHed into a remote machine, if I run a command that spews a lot of text, how quickly does the terminal respond to ^C, stop printing text, and return me to the prompt.
joosters 9y ago
In my experience, the speed of a terminal responding to a ^C is highly correlated with the speed of its output. It's true that there's no need for a slow rendering terminal to also be slow at reacting to ^C, but it always tends to be the slow terminals that jam up. I agree totally with the speed of display updates not really being important - if my terminal is spewing hundreds of pages of text, it doesn't matter whether it's redrawing at 50fps or 5fps. My hunch is that the slowest terminals are the ones that insist upon drawing every single character of output. They then end up with a huge buffer of text that needs to be rendered even though the ^C may have been sent and the noisy program has been terminated.
- btilly 9y ago
  The author of the article just benchmarked a bunch of performance stuff about terminals under different conditions. He said that in his benchmarks they are not well correlated and gave a specific terminal which specifically demonstrates it. I trust the author's benchmarks over your experience. (Doubly so since my experience matches the author's.)
Tyriar 9y ago
I looked into this quite a bit when I was optimizing xterm.js. Based on my findings, ^C is highly related to the speed of the output because the process running in the shell may be way ahead of the terminal's parsing/rendering. Imagine you run `cat foo`, the shell could take around 1s to send the output over to the terminal, the terminal might then take 10 seconds to parse and render the output. So after 1 second a ^C will actually do nothing because the cat call has finished. This is the case with Hyper, it hangs due to slow parsing and too much DOM interaction (as hterm was not designed for this sort of thing). There's actually a mechanism for telling the process to pause and resume (sending XOFF/XON signals), which allows the terminal and shell to stay completely in sync (^C very responsive). However, these only really work well in bash as oh-my-zsh for example overrides the signal with a custom keybinding. Related links: Original PR: https://github.com/sourcelair/xterm.js/pull/447 https://github.com/sourcelair/xterm.js/pull/447 Post-PR bug: https://github.com/sourcelair/xterm.js/issues/511 https://github.com/sourcelair/xterm.js/issues/511
- btilly 9y ago
  Well, given that I mostly use the default shell for my system, which tends to be bash, I prefer shells that send XOFF/XON signals. And now I can pick a very responsive terminal over a fast rendering one. :-) If this becomes popular enough, then zsh will figure out how to offer the feature that bash already does, and terminals will happily adopt it. Then everyone's lives are better! :-)
- scottlamb 9y ago
  If the sending process blocks after filling the pipe (on Linux, 512 bytes), hitting ctrl-C should be effective—any of these terminals should be able to sink that in negligible time. If it instead takes a long time, there are probably large buffers between: * If you're talking about ssh to a faraway machine, the TCP layer is probably responsible. (I'm not even sure if there's anything you can do about this; the buffer (aka "window size" in TCP terminology, plus the send and receive buffers on their respective ends) is meant to be at least the bandwidth-delay product, and as far as I know, the OS doesn't provide an interface to tell it you don't need a lot of bandwidth for this connection. It'd be nice if you could limit the TCP connection's bandwidth to what the terminal could sink.) * If you're talking about something running on the machine itself, it's probably an over-large buffer inside the terminal program itself.

kps 9y ago

That's what 'stty discard' was for, but apparently Linux doesn't implement it.

spudlyo 9y ago
Reminds me of my 300/1200 baud days, when you couldn't live without it.

glangdale 9y ago

This might be a dumb question, but why do terminals spew output anyhow? Past a certain point it's clearly unreadable. Once the terminal starts getting behind this is a UI failure IMO. So why not (say) buffer it up somewhere, show a preview, show a "I would be spewing output right now, press <Space> to see what the last screen is, press Ctrl-C to stop, press 's' to just spew output". The speeds and amounts of data for which this happens could be completely configurable. You can always put a limit on how much to buffer up (I'm not saying that this system should completely buffer output files until you run out of disk space), and sometimes 'spewing' is actually what we want.

cat199 9y ago
Hardware terminals had this feature, ish. The vt220 had a 'slow scroll' speed which would buffer text and scroll it at a viewable speed, limited by the quite small memory on the screen. It also had a 'pause' key which would pause the display and then continue the output (again limited by the terminal's memory). See also PC 'scroll lock' key.
dredmorbius 9y ago
Not a dumb question at all. Various tools can and do deal with the spew though. Ofhand, script (typescript), screen, and tmux. If you're running a session through a serial terminal emulator (e.g., minicom), that would be another instance. I'm not going to claim these are particularly mainstream uses (though I've made use of each of them, and been grateful for the ability to do so). But they do exist, and I suspect there are others.
JdeBP 9y ago
You might want to read up on the design of mosh. The way to tackle this is not to "buffer output up". In fact, the way to tackle this is the opposite of filling up buffers with output. It is to decouple the terminal emulation from the rendering. Mosh runs the terminal emulator on the remote server machine, and transmits snapshots of state (using a difference algorithm for efficiency) at regular intervals over the network to the client, which renders the terminal state snapshots to the display on the local client.