Terminal Latency (2017) • Hacker News Board

Re: Terminal Latency (2017)

#41

Post by modeless » Fri, Aug 12, 2022, 3:11 AM UTC

ad8e wrote: post #40

modeless wrote: post #19

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…

> 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 cau…

I discuss tearing here: https://james.darpinian.com/blog/latency-techniques#tearing-... and here 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.

Re: Terminal Latency (2017)

#42

Post by ad8e » Fri, Aug 12, 2022, 3:46 AM UTC

modeless wrote: post #41

ad8e wrote: post #40

Earlier quoted context omitted.

> 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 cau…

I discuss tearing here: https://james.darpinian.com/blog/latency-techniques#tearing-... and here 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…

On a non-VRR display, I believe it's nicer to have a momentary tearline near the top of the screen than a momentary frame skip. The stutter is more noticeable than the tearline. (Some feature of how GPUs work means that tearlines landing exactly at vsync are mysteriously delayed half a frame. Maybe someone else knows why, since I don't and neither do the people I talked to.)

Re: Terminal Latency (2017)

#43

Post by tingletech » Sun, Aug 14, 2022, 5:41 PM UTC

icedchai wrote: post #39

tingletech wrote: post #37

Earlier quoted context omitted.

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…

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.

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.