Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Carmack probably read the Anandtech article (from 2009) on this topic: http://www.anandtech.com/print/2803

So the short answer is: it takes that long to go through all of the processors (input controller/keyb/mouse, usb, cpu, processing latency, gpu, more processing latency, RAMDAC/digital output, LCD pre-processing, LCD output, LCD post-processing, pixel transistor)

He doesn't mention using "game mode" on that display - maybe it doesn't have one. Game mode is supposed to minimize pre- and post-processing to minimize LCD latency, exactly for this reason.

Also note it takes about that long for signals to hit your eye, go through your brain, hit a switch that fires an action, that signal to travel down your arm and back into your finger ~ 113ms.

(How does that line up with 100ms game tick cycles? I don't know.)



If you read the link, he actually describes his methodology:

"The time to send a packet to a remote host is half the time reported by ping, which measures a round trip time.

The display I was measuring was a Sony HMZ-T1 head mounted display connected to a PC.

To measure display latency, I have a small program that sits in a spin loop polling a game controller, doing a clear to a different color and swapping buffers whenever a button is pressed. I video record showing both the game controller and the screen with a 240 fps camera, then count the number of frames between the button being pressed and the screen starting to show a change.

The game controller updates at 250 hz, but there is no direct way to measure the latency on the input path (I wish I could still wire things to a parallel port and use in/out Sam instructions). As a control experiment, I do the same test on an old CRT display with a 170hz vertical retrace. Aero and multimon can introduce extra latency, but under optimal conditions you will usually see a color change starting at some point on the screen (vsync disabled) two 240 hz frames after the button goes down. It seems there is 8ms or so of latency going through the USB HID processing, but I would like to nail this down better in the future.

It is not uncommon to see desktop LCD monitors take 10+ 240hz frames to show a change on the screen. The Sony HMZ averaged around 18 frames, or 70+ total milliseconds."


This agrees with Anand's results - with vsync disabled and very fast input processing, you could have about 17ms for transmission from the video card (in the video cable), another 17ms for processing, and 4ms more for LCD response, giving the ~40ms that 10 frames would give.

(1/240 sec = .075/18 = .0041667 sec = 4.1667 ms)


This is why I play Geometry Wars on a Sony Trinitron CRT TV.

> "you will usually see a color change starting at some point on the screen (vsync disabled) two 240 hz frames after the button goes down"

That's less than 1/100th of a second from the button press to the screen.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: