6 ms·

> you can easily setup a command line interface or Linux system and move blazing fast Well... not really. Terminal response times are way slower than they used

> you can easily setup a command line interface or Linux system and move blazing fast Well... not really. Terminal response times are way slower than they used to be in the 80's. Sure, we have greater throughput, but we also have greater latency. https://danluu.com/term-latency/ https://danluu.com/term-latency/

GekkePrutser 7y ago
Not really :) Consider a VT100. It could only go up to 19200 baud, and couldn't actually handle constant streams at that speed. However I do agree with the general message of the article. Current UX is a mess, websites are overblown by tons of javascript. There's no reason there should be loading spinners in this day and age with the power we have at our fingertips.
- jws 7y ago
  Consider a VT100. It could only go up to 19200 baud… The VMS manuals suggested that system administrators may want to keep the hard wired terminals down to 2400 buad and hide the fact from users by turning on "smooth scroll" (which only scrolled about that fast anyway) in order to keep the interrupt load down on the Vax. Something about batching of interrupts on the multiport serial cards.
  - GekkePrutser 7y ago
    Yes there was that but it also just couldn't handle the full speed continuously. It depended a lot what kind of commands were sent. Full text was fairly OK but drawing commands took a while as far as I remember. In any case, flow control was a must-have in those days. Either CTS/RTS or at least XON/XOFF
- ralusek 7y ago
  There's no reason there should be loading spinners in this day and age...when spinners are almost exclusively used in web apps in order to denote that the web browser is yet to receive the necessary data over YOUR internet connection.
  - kokx 7y ago
    Tell that to my former boss. They wanted me to delay sending responses from the backend, because they liked showing off their custom spinner. The spinner would not be seen at all during normal operation, without the delay in sending responses.
  - GekkePrutser 7y ago
    Then why do I still see them with my verified 600/600 connection :) The problem is just that there's too much javascript running in the browser and it's too poorly written (loading each post individually in Reddit by example instead of batching them). Reddit's redesign in particular is really really bad. At least they offer the old site but it looks so bad. I'd love to have something looking more modern but without the javascript overload.
RHSeeger 7y ago
> Terminal response times are way slower than they used to be in the 80's. Do you have data / a citation to back up that statement? Most things seem faster to me. As long as the command line responds as faster as I can type, I don't care about it being faster. That being said, overall speed and what can be handled by the system certainly does matter in many cases, even if it is _just throughput_. I've recently been running commands to search/process data from the command line recently 1. Search through a directory structure with millions of files (find) 2. filter down to ones containing a certain thing (grep) 3. find certain values in the files based on pattern matching (sed) 4. filter to files where one value equals another (test) I can't imagine that would _ever_ finish running on a computer in the 80s. It works just fine on my current computer (albeit taking a minute to run).
- 113 7y ago
  > Do you have data / a citation to back up that statement? It's at the end of their comment.
  - cgriswald 7y ago
    That citation does not support the quoted claim.
  - RHSeeger 7y ago
    The page in question discusses latency in terminals, not how it compares to performance of previous generations. That being said, it also seems to have to pull in the 99th percentile behavior in order for the timings to be an issue, and even then it's not horrible; it doesn't get actually "bad" until you consider the worst performance (99.9th percentile) of the worst performer (st). It seems overly picky to me.
    - soulofmischief 7y ago
      https://lwn.net/Articles/751763/ https://lwn.net/Articles/751763/ Here is another survey which takes it from a different angle. I should have clarified my original post but it's too late: I am lamenting primarily against the latency introduced by the amount of layers involved both at the hardware and software level compared to yesteryear. Compositors, virtualization, higher level languages, etc. do not come for free; despite explosive increases in computing capability, we also have an explosive increase in the number of running threads and the resources required to maintain them.
deleted 7y ago
[deleted]
ModernMech 7y ago
There's also this: https://github.com/microsoft/terminal/issues/143 https://github.com/microsoft/terminal/issues/143 (Weird slowness scolling text in the console ) """ It's caused by conhost.exe excessively hammering the registry to query the following two values: HKCU\Software\Microsoft\Windows\CurrentVersion\ImmersiveShell\TabletMode HKCU\Software\Microsoft\Windows\DWM\ColorPrevalence Having previously reported this issue through Feedback Hub (to no avail), let me offer my observations from debugging this issue: It's not specific to Dell's XPS series - I've been able to reproduce on any Windows 10 installation from version 1703 and up It only occurs when the console application writes output that causes the console to scroll It only occurs when the console application in question is in foreground/focus Each reg value mentioned above is queried 6 times, per scroll!!! """ The solution I use is to minimize the terminal when it's scrolling. When I compile my projects if I don't minimize the terminal it takes forever to finish.
- opless 7y ago
  It's a very common problem/solution. Since the beginning of Windows NT I believe
mrdatawolf 7y ago
"Terminal response times are way slower than they used to be in the 80's." In 1983 the top selling computers were the TRS-80, Apple II and IBM PC (among others). I started on those computers. And what you said is crap... straight out BS. Any person from that era should remember what happened when you typed dir (or equivalent) into a folder with a couple hundred items. It was time to go make some coffee while each...item...was...written...to...the...screen. The OP has good points but the start was WEAK because it is factually inaccurate like your comment.
- simonskoog 7y ago
  That still happens though, and it's not because it actually took 50ms for your computer to read a filename and 500 ms for it to read 10. It depends on how fast you allow items to be written (pixels per unit of time) on your display and if you force writing of everything or allow line skips. If you want to experiment I think putty has pretty fine-grain control options.
- carapace 7y ago
  Right, I can recall the first time I saw my friend's parent's 486. I remember doing 'dir' on a large directory, it scrolled so fast, so fast. I said to my friend, "The next generation will be so fast it will have finished scrolling before you finish typing the command." Sadly, it was not to be. DOS on a 486 is as fast as computers have ever gotten, perceptually.
- deleted 7y ago
  [deleted]
- soulofmischief 7y ago
  The terminal is not experiencing input latency while the shell runs the dir program. The drawing program is experiencing latency. My comment is oversimplified for brevity, but not factually incorrect.

GekkePrutser 7y ago

Not really :) Consider a VT100. It could only go up to 19200 baud, and couldn't actually handle constant streams at that speed. However I do agree with the general message of the article. Current UX is a mess, websites are overblown by tons of javascript. There's no reason there should be loading spinners in this day and age with the power we have at our fingertips.

jws 7y ago
Consider a VT100. It could only go up to 19200 baud… The VMS manuals suggested that system administrators may want to keep the hard wired terminals down to 2400 buad and hide the fact from users by turning on "smooth scroll" (which only scrolled about that fast anyway) in order to keep the interrupt load down on the Vax. Something about batching of interrupts on the multiport serial cards.
- GekkePrutser 7y ago
  Yes there was that but it also just couldn't handle the full speed continuously. It depended a lot what kind of commands were sent. Full text was fairly OK but drawing commands took a while as far as I remember. In any case, flow control was a must-have in those days. Either CTS/RTS or at least XON/XOFF
ralusek 7y ago
There's no reason there should be loading spinners in this day and age...when spinners are almost exclusively used in web apps in order to denote that the web browser is yet to receive the necessary data over YOUR internet connection.
- kokx 7y ago
  Tell that to my former boss. They wanted me to delay sending responses from the backend, because they liked showing off their custom spinner. The spinner would not be seen at all during normal operation, without the delay in sending responses.
- GekkePrutser 7y ago
  Then why do I still see them with my verified 600/600 connection :) The problem is just that there's too much javascript running in the browser and it's too poorly written (loading each post individually in Reddit by example instead of batching them). Reddit's redesign in particular is really really bad. At least they offer the old site but it looks so bad. I'd love to have something looking more modern but without the javascript overload.

RHSeeger 7y ago

> Terminal response times are way slower than they used to be in the 80's. Do you have data / a citation to back up that statement? Most things seem faster to me. As long as the command line responds as faster as I can type, I don't care about it being faster. That being said, overall speed and what can be handled by the system certainly does matter in many cases, even if it is _just throughput_. I've recently been running commands to search/process data from the command line recently 1. Search through a directory structure with millions of files (find) 2. filter down to ones containing a certain thing (grep) 3. find certain values in the files based on pattern matching (sed) 4. filter to files where one value equals another (test) I can't imagine that would _ever_ finish running on a computer in the 80s. It works just fine on my current computer (albeit taking a minute to run).

113 7y ago
> Do you have data / a citation to back up that statement? It's at the end of their comment.
- cgriswald 7y ago
  That citation does not support the quoted claim.
- RHSeeger 7y ago
  The page in question discusses latency in terminals, not how it compares to performance of previous generations. That being said, it also seems to have to pull in the 99th percentile behavior in order for the timings to be an issue, and even then it's not horrible; it doesn't get actually "bad" until you consider the worst performance (99.9th percentile) of the worst performer (st). It seems overly picky to me.
  - soulofmischief 7y ago
    https://lwn.net/Articles/751763/ https://lwn.net/Articles/751763/ Here is another survey which takes it from a different angle. I should have clarified my original post but it's too late: I am lamenting primarily against the latency introduced by the amount of layers involved both at the hardware and software level compared to yesteryear. Compositors, virtualization, higher level languages, etc. do not come for free; despite explosive increases in computing capability, we also have an explosive increase in the number of running threads and the resources required to maintain them.

deleted 7y ago

[deleted]

ModernMech 7y ago

There's also this: https://github.com/microsoft/terminal/issues/143 https://github.com/microsoft/terminal/issues/143 (Weird slowness scolling text in the console ) """ It's caused by conhost.exe excessively hammering the registry to query the following two values: HKCU\Software\Microsoft\Windows\CurrentVersion\ImmersiveShell\TabletMode HKCU\Software\Microsoft\Windows\DWM\ColorPrevalence Having previously reported this issue through Feedback Hub (to no avail), let me offer my observations from debugging this issue: It's not specific to Dell's XPS series - I've been able to reproduce on any Windows 10 installation from version 1703 and up It only occurs when the console application writes output that causes the console to scroll It only occurs when the console application in question is in foreground/focus Each reg value mentioned above is queried 6 times, per scroll!!! """ The solution I use is to minimize the terminal when it's scrolling. When I compile my projects if I don't minimize the terminal it takes forever to finish.

opless 7y ago
It's a very common problem/solution. Since the beginning of Windows NT I believe

mrdatawolf 7y ago

"Terminal response times are way slower than they used to be in the 80's." In 1983 the top selling computers were the TRS-80, Apple II and IBM PC (among others). I started on those computers. And what you said is crap... straight out BS. Any person from that era should remember what happened when you typed dir (or equivalent) into a folder with a couple hundred items. It was time to go make some coffee while each...item...was...written...to...the...screen. The OP has good points but the start was WEAK because it is factually inaccurate like your comment.

simonskoog 7y ago
That still happens though, and it's not because it actually took 50ms for your computer to read a filename and 500 ms for it to read 10. It depends on how fast you allow items to be written (pixels per unit of time) on your display and if you force writing of everything or allow line skips. If you want to experiment I think putty has pretty fine-grain control options.
carapace 7y ago
Right, I can recall the first time I saw my friend's parent's 486. I remember doing 'dir' on a large directory, it scrolled so fast, so fast. I said to my friend, "The next generation will be so fast it will have finished scrolling before you finish typing the command." Sadly, it was not to be. DOS on a 486 is as fast as computers have ever gotten, perceptually.
deleted 7y ago
[deleted]
soulofmischief 7y ago
The terminal is not experiencing input latency while the shell runs the dir program. The drawing program is experiencing latency. My comment is oversimplified for brevity, but not factually incorrect.