Dawn of the Geeks

Digg recently ran an article about what latency is and what causes it. I pointed out that latency is often caused by software. Not the internet. Of course this comment was dugg down by people who assume that graphics cards and sound cards free up CPU time to handle messages promptly. This is the problem with the internet: people who have never actually created an on-line game make silly assumptions and act like they know something.

Real world example: I created a simulator using DEM (geological survey data) to render real terrain using OpenGL. This simulator had two parts. The first part was the graphical application that rendered everything. It didn’t do much of any logic. It was just told what was were and what direction it was moving and how fast. The second part was any number of clients controlling any number of objects. The clients rendered exactly no graphics whatsoever. They were text apps that just bombarded the server with messages.

Fact: when the server was not restricted in the frame rate it would crash after a few minutes because it didn’t have enough time to process all the messages. The buffer would get full and it could no longer receive messages. If I had it only process a few messages per frame it only delayed the inevitable crash when the message buffer overflowed and it stopped receiving messages. If I had it process all messages before rendering a frame it would just stop rendering frames after awhile.

The lesson: it doesn’t matter that the graphics card was doing all the heavy lifting. If framerates were priority there simply wasn’t enough horsepower left to handle messages. This was a 3ghz machine with a nice graphics card. Also, if the message buffer can’t be emptied faster than messages are coming in you also have a problem. This indicates a necessity for an efficient protocol and finding ways to reduce the need for a large number of messages being sent. It is also necessary to give the program ample CPU time to process messages and this means restricting frame rates.

Second Real World Example: Sack Armies (which will be running live one of these days) also relies on TCP for the messaging protocol. There are no throw away messages so a guarenteed protocol was necessary. When I first started I was treating TCP like a messaging protocol. The server would process a message from a client, form a response and send it off right away. Certain actions required more than one message to be sent. Back on the client side the first message would come in and then a pause and then the second message.

This happened when the server and client were on the same computer or on the same network. That’s latency. The solution? Instead of sending the messages right away they were buffered both on the client side and the server side. The server would flush its buffer (actually send the messages down the pipe) once per iteration of the main loop which was running at 100’s of iterations per second. The client would buffer all the data coming in and process messages once per interation as well. The client would also only send messages once per iteration as well.

Keep in mind that with a couple if statements it’s possible to run the main loop at thousands of iterations per second while only rendering new frames a fraction of the time.

The result? No perceived latency. Because, for example, three messages were sent all at once, the client got them more or less all at once and processed them all before the next frame was rendered.

I set up a message type for testing the latency. The client would put a message into the out buffer and start a timer. The message would be fired off and the server would get the message and put a response into the out buffer on its end. The server would then send the response to the client. The client would get it, buffer it and then process it. The entire process took 30ms or less even with miles between the client and server and different internet companies.