Live data from Hacker News

Terminal Latency (2017)

danluu.com

11–20 of 43 posts

Re: Terminal Latency (2017)

#11

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

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.

Re: Terminal Latency (2017)

#12
post #8

~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 w…

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/193480622533...

Re: Terminal Latency (2017)

#13

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

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.

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.

Re: Terminal Latency (2017)

#16
post #8

~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 w…

I don't know too much about the whole graphics pipeline, but this is definitely double-counting.

I will say though, whatever the numbers are, after running on a 144hz monitor with adaptive sync, 60 FPS feels painfully jerky for gaming.

Re: Terminal Latency (2017)

#17
post #8

~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 w…

Yeah I'm with you .. even with double buffering these numbers don't hold water

Re: Terminal Latency (2017)

#18
post #6

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

I did, I switched to kitty, because of Wayland. It feels crazy responsive even without looking at tests

Re: Terminal Latency (2017)

#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 ways to improve latency:

Intro: https://james.darpinian.com/blog/latency

Techniques to improve latency in your applications: https://james.darpinian.com/blog/latency-techniques

Platform-specific considerations: https://james.darpinian.com/blog/latency-platform-considerat...

Re: Terminal Latency (2017)

#20

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

Those terminals were a huge upgrade over the 300-1200 baud modem connections in the 80s...

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 / 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.
Post reply on HN