6 ms·

If you're sensitive to latency and run Linux, try hitting Ctrl-Alt-F1, and do a little work in console mode at the terminal. (Ctrl-Alt-F7 to get back.) For me

by chubot 9y ago

If you're sensitive to latency and run Linux, try hitting Ctrl-Alt-F1, and do a little work in console mode at the terminal. (Ctrl-Alt-F7 to get back.) For me this is a great illustration of how much latency there is in the GUI. Not sure if everyone can feel it, but to me console mode is much more immediate and less "stuffy".

Kenji 9y ago
Meanwhile on Windows 10 it sometimes takes 2 seconds until the start menu pops up, or sometimes a full second until a right-click context menu comes up. On a clean Windows 10 install on a 3.4GHz PC with plenty of RAM :)
- steveklabnik 9y ago
  PowerShell gives you an interesting little number when you start it up: Windows PowerShell Copyright (C) 2016 Microsoft Corporation. All rights reserved. Loading personal and system profiles took 542ms.
  - martindevans 9y ago
    Mine does not give me that number - do I need to do something to turn it on?
    - steveklabnik 9y ago
      I don't think so; I didn't explicitly do anything. I have a Lenovo and they put all kinds of crap on there, so maybe this had something to do with it, I dunno.
    - edmccard 9y ago
      >do I need to do something to turn it on? I think it doesn't display if your profiles take less than 500ms to load. EDIT: Just tested with a clean profile with the line "Start-Sleep -m xxxx" for various values of xxxx, and the message has shown up with times just above 500ms but not below.
- avaer 9y ago
  I do everything with a full Debian VM which I SSH into from a Javascript SSH client running in Chrome. This is generally much more performant than doing things in the Windows 10 shell.
- flukus 9y ago
  For the start menu, I'm guessing this is either hard drive latency or network latency. The network latency can be particularly bad if you have an intermittent connection, like when you connect to a mobile hotspot on your phone from a moving train, the start menu can hang for minutes. It would literally be faster to reboot the computer than to wait for the start menu to popup.
  - Kenji 9y ago
    I have a SSD and fast internet with low ping. Besides, the start menu shouldn't need to connect to the internet.
ezequiel-garzon 9y ago
I wonder how many folks use linux virtual consoles for day-to-day work. I guess it's not practical for web developers given that you probably have to switch to X to check results with a graphical browser, no?
- lottin 9y ago
  As far as I know Linux VTs were never meant to be used for real work, but as a last resort in emergency situations. Fonts for example are limited to 256 glyphs, which means most non-English languages are only partially supported.
  - zorked 9y ago
    Linux VTs is all we had for a long time. Even if X was around, not everybody had computers powerful enough to comfortably run X. I had a computer that would swap just by having X open with fvwm.
    - pm215 9y ago
      Mmm. If you want an example of a console that seemingly was never meant to be used for real work, try the old Sun SPARCStation Solaris consoles. Those were implemented using the boot PROM's graphics drivers which were written in Forth and not exactly optimised for speed. https://www.youtube.com/watch?v=ntJmmI6iIEc https://www.youtube.com/watch?v=ntJmmI6iIEc has an example starting at about 0:50 -- it used to feel like you could practically watch the cursor moving from left to right as it printed longer lines... (I think Sun assumed you'd either be logging in remotely or using a graphical windowing system, so they never worried about the performance of the text console. Linux on the same hardware installed its own video driver written in C for the terminal so it was dramatically faster.)
      - cat199 9y ago
        Still faster than a hardware terminal... I wouldn't be surprised if it was meant to emulate these to some degree..
jerf 9y ago
You may need to do some work to boot your console into text mode. If your linux console is using graphics mode even on modern systems it can still be a dog, especially at 4K. Presumably this is a result of using ancient lowest-common-denominator interfaces since my system has the raw power to run a snappy text-mode only terminal.
- chubot 9y ago
  Oh do you have details on this? I recall doing this on an older machine and I would get an 80x25 terminal. Now when I do it, I get a high-res display. I guess the latter is in graphics mode? It definitely has slow throughput at catting files, e.g. if I cat the output of "seq 100000". The latency seems better though. Probably not as good as text mode. I honestly don't know what text/console mode even is. I know there is a VGA "spec" -- I think all graphics drivers for PC-compatible devices have to support VGA and text mode? Or is it part of the BIOS?
  - cat199 9y ago
    Not an expert, but basically 'text mode' entails something like directly putting the text characters into a memory buffer, and the monitor rendering those in hardware via onboard fonts.
  - TheDong 9y ago
    The resolution change is likely the result of Kernel Mode Setting (KMS). This is the ability for the linux kernel itself to set the resolution of the display, among other things. The easiest way to turn it off is to add "nomodeset" to your kernel commandline. The correct term, by the way, is not "text mode", but rather "a virtual console" or "virtual tty" or such. Hopefully that gives you enough search terms to learn more.
    - JdeBP 9y ago
      Actually, the correct term is text mode. It is precisely whether the display hardware is operating in text mode or graphics mode that is the subject of discussion here. With the hardware in text mode, even without CRTC tricks, scrolling is relatively fast compared to graphics mode. Scrolling the display in graphics mode involves shifting much more data around, as does rendering individual characters. The confusion arises because people, as you have done, erroneously conflate the kernel virtual terminals with "text mode". In fact, the norm nowadays is for kernel virtual terminals to use graphics mode. It permits a far larger glyph repertoire and more colours, for starters, as well as things like software cursors that can be a wider range of shapes and sprites for mouse pointers.
skywhopper 9y ago
Yeah, text-mode latency (or lack thereof) is incredible. For the most jarring difference, try the Ctrl-C trick mentioned in article: `cat` a huge text file that takes many seconds to read from disk in your gui console, wait a couple of seconds, hit Ctrl-C, and compare that to the same exercise in the console.
- barrkel 9y ago
  Most "modern" GUI terminals make this artificially fast by not rendering every flushed buffer; instead, they simulate what ought to be on screen, and then render at 60Hz or whatever your refresh rate is. The point being that it's not measuring latency, nor throughput of the rendering, but rather throughput of the emulation.
  - clord 9y ago
    You're describing exactly what makes them feel slow. All of that buffering is adding latency. Everything is buffering: the screen, the GPU, the OS, the window manager, the shell. People notice the extra latency though. I sure do. I remember what it's like to have a CRT getting photons displayed nearly immediately after a keystroke. That's exactly what makes an old 286 feel snappier than a 2017 macbook pro while typing.
    - JdeBP 9y ago
      I remember how slow it was accessing text mode video RAM on the ISA bus compared to constructing a display in main RAM, and indeed buffering changes there and rendering them across en bloc to video RAM. Buffering is not a recent invention.
rnhmjoj 9y ago
I would really like to use just the linux virtual terminal. Unfortunately it has no unicode support and there is an unsolved issue with amd GPUs that causes the switching from a vt to X.org to take an unbearable amount of time. I have to look into Kmscon which seems promising.
- chubot 9y ago
  Is it a GPU issue? I have an NVidia GPU and I still wouldn't regularly hit Ctrl-Alt-F1/F7 to switch tasks. Estimating, it takes at least 500 - 1500 ms. I have no idea what's happening here... if it's an X thing, a driver thing, etc. I don't recall it being fast on any machine I've used recently. It's at least 100x slower than it should be to be usable -- it should be around 5 to 15 ms, or even less.
  - rnhmjoj 9y ago
    In my case the delay is much worse: around 5s. It seems to be related to DPM. The only description of the problem I have found is here: https://bugs.freedesktop.org/show_bug.cgi?id=92982f https://bugs.freedesktop.org/show_bug.cgi?id=92982f
rdslw 9y ago
I recommend this to every terminal user. I'm a fast typer, but this is 2017 - computers are fast, right? Nope. On newest, maxed dell xps there is a HUGE latency difference I feel if I use pure linux console vs any graphical one (is it gnome/windows or mac). Typing and working with pure text is really fast and you INSTANTLY feel and see the difference. Try it.

by chubot 9y ago

Kenji 9y ago

Meanwhile on Windows 10 it sometimes takes 2 seconds until the start menu pops up, or sometimes a full second until a right-click context menu comes up. On a clean Windows 10 install on a 3.4GHz PC with plenty of RAM :)

steveklabnik 9y ago
PowerShell gives you an interesting little number when you start it up: Windows PowerShell Copyright (C) 2016 Microsoft Corporation. All rights reserved. Loading personal and system profiles took 542ms.
- martindevans 9y ago
  Mine does not give me that number - do I need to do something to turn it on?
  - steveklabnik 9y ago
    I don't think so; I didn't explicitly do anything. I have a Lenovo and they put all kinds of crap on there, so maybe this had something to do with it, I dunno.
  - edmccard 9y ago
    >do I need to do something to turn it on? I think it doesn't display if your profiles take less than 500ms to load. EDIT: Just tested with a clean profile with the line "Start-Sleep -m xxxx" for various values of xxxx, and the message has shown up with times just above 500ms but not below.
avaer 9y ago
I do everything with a full Debian VM which I SSH into from a Javascript SSH client running in Chrome. This is generally much more performant than doing things in the Windows 10 shell.
flukus 9y ago
For the start menu, I'm guessing this is either hard drive latency or network latency. The network latency can be particularly bad if you have an intermittent connection, like when you connect to a mobile hotspot on your phone from a moving train, the start menu can hang for minutes. It would literally be faster to reboot the computer than to wait for the start menu to popup.
- Kenji 9y ago
  I have a SSD and fast internet with low ping. Besides, the start menu shouldn't need to connect to the internet.

ezequiel-garzon 9y ago

I wonder how many folks use linux virtual consoles for day-to-day work. I guess it's not practical for web developers given that you probably have to switch to X to check results with a graphical browser, no?

lottin 9y ago
As far as I know Linux VTs were never meant to be used for real work, but as a last resort in emergency situations. Fonts for example are limited to 256 glyphs, which means most non-English languages are only partially supported.
- zorked 9y ago
  Linux VTs is all we had for a long time. Even if X was around, not everybody had computers powerful enough to comfortably run X. I had a computer that would swap just by having X open with fvwm.
  - pm215 9y ago
    Mmm. If you want an example of a console that seemingly was never meant to be used for real work, try the old Sun SPARCStation Solaris consoles. Those were implemented using the boot PROM's graphics drivers which were written in Forth and not exactly optimised for speed. https://www.youtube.com/watch?v=ntJmmI6iIEc https://www.youtube.com/watch?v=ntJmmI6iIEc has an example starting at about 0:50 -- it used to feel like you could practically watch the cursor moving from left to right as it printed longer lines... (I think Sun assumed you'd either be logging in remotely or using a graphical windowing system, so they never worried about the performance of the text console. Linux on the same hardware installed its own video driver written in C for the terminal so it was dramatically faster.)
    - cat199 9y ago
      Still faster than a hardware terminal... I wouldn't be surprised if it was meant to emulate these to some degree..

jerf 9y ago

You may need to do some work to boot your console into text mode. If your linux console is using graphics mode even on modern systems it can still be a dog, especially at 4K. Presumably this is a result of using ancient lowest-common-denominator interfaces since my system has the raw power to run a snappy text-mode only terminal.

chubot 9y ago
Oh do you have details on this? I recall doing this on an older machine and I would get an 80x25 terminal. Now when I do it, I get a high-res display. I guess the latter is in graphics mode? It definitely has slow throughput at catting files, e.g. if I cat the output of "seq 100000". The latency seems better though. Probably not as good as text mode. I honestly don't know what text/console mode even is. I know there is a VGA "spec" -- I think all graphics drivers for PC-compatible devices have to support VGA and text mode? Or is it part of the BIOS?
- cat199 9y ago
  Not an expert, but basically 'text mode' entails something like directly putting the text characters into a memory buffer, and the monitor rendering those in hardware via onboard fonts.
- TheDong 9y ago
  The resolution change is likely the result of Kernel Mode Setting (KMS). This is the ability for the linux kernel itself to set the resolution of the display, among other things. The easiest way to turn it off is to add "nomodeset" to your kernel commandline. The correct term, by the way, is not "text mode", but rather "a virtual console" or "virtual tty" or such. Hopefully that gives you enough search terms to learn more.
  - JdeBP 9y ago
    Actually, the correct term is text mode. It is precisely whether the display hardware is operating in text mode or graphics mode that is the subject of discussion here. With the hardware in text mode, even without CRTC tricks, scrolling is relatively fast compared to graphics mode. Scrolling the display in graphics mode involves shifting much more data around, as does rendering individual characters. The confusion arises because people, as you have done, erroneously conflate the kernel virtual terminals with "text mode". In fact, the norm nowadays is for kernel virtual terminals to use graphics mode. It permits a far larger glyph repertoire and more colours, for starters, as well as things like software cursors that can be a wider range of shapes and sprites for mouse pointers.

skywhopper 9y ago

Yeah, text-mode latency (or lack thereof) is incredible. For the most jarring difference, try the Ctrl-C trick mentioned in article: `cat` a huge text file that takes many seconds to read from disk in your gui console, wait a couple of seconds, hit Ctrl-C, and compare that to the same exercise in the console.

barrkel 9y ago
Most "modern" GUI terminals make this artificially fast by not rendering every flushed buffer; instead, they simulate what ought to be on screen, and then render at 60Hz or whatever your refresh rate is. The point being that it's not measuring latency, nor throughput of the rendering, but rather throughput of the emulation.
- clord 9y ago
  You're describing exactly what makes them feel slow. All of that buffering is adding latency. Everything is buffering: the screen, the GPU, the OS, the window manager, the shell. People notice the extra latency though. I sure do. I remember what it's like to have a CRT getting photons displayed nearly immediately after a keystroke. That's exactly what makes an old 286 feel snappier than a 2017 macbook pro while typing.
  - JdeBP 9y ago
    I remember how slow it was accessing text mode video RAM on the ISA bus compared to constructing a display in main RAM, and indeed buffering changes there and rendering them across en bloc to video RAM. Buffering is not a recent invention.

rnhmjoj 9y ago

I would really like to use just the linux virtual terminal. Unfortunately it has no unicode support and there is an unsolved issue with amd GPUs that causes the switching from a vt to X.org to take an unbearable amount of time. I have to look into Kmscon which seems promising.

chubot 9y ago
Is it a GPU issue? I have an NVidia GPU and I still wouldn't regularly hit Ctrl-Alt-F1/F7 to switch tasks. Estimating, it takes at least 500 - 1500 ms. I have no idea what's happening here... if it's an X thing, a driver thing, etc. I don't recall it being fast on any machine I've used recently. It's at least 100x slower than it should be to be usable -- it should be around 5 to 15 ms, or even less.
- rnhmjoj 9y ago
  In my case the delay is much worse: around 5s. It seems to be related to DPM. The only description of the problem I have found is here: https://bugs.freedesktop.org/show_bug.cgi?id=92982f https://bugs.freedesktop.org/show_bug.cgi?id=92982f

rdslw 9y ago

I recommend this to every terminal user. I'm a fast typer, but this is 2017 - computers are fast, right? Nope. On newest, maxed dell xps there is a HUGE latency difference I feel if I use pure linux console vs any graphical one (is it gnome/windows or mac). Typing and working with pure text is really fast and you INSTANTLY feel and see the difference. Try it.