So far I've always used a time granularity of 1 msec (that's it, 1 millisecond is the atomic time unit).

I'm wondering if this is always fine, or if for some cases (some specific games, game components or platforms) it would be suggested to have a more accurate time unit (on the order of microseconds or, I don't know, hundreds of microseconds).

  • \$\begingroup\$ You would be struggling to get that kind of accuracy. There's no gurantee you can run by the millisecond on desktop platforms, IIRC. \$\endgroup\$ Dec 23, 2010 at 11:49
  • \$\begingroup\$ Actually newer systems (real time OSes, many BSDs and patched Linux kernels) are even starting to support nanoseconds (although they cannot be very accurate). The time granularity offered by any Linux system is on the order of microseconds (10 msecs at most, IIRC). \$\endgroup\$
    – peoro
    Dec 23, 2010 at 12:44
  • \$\begingroup\$ 10usec is the usual measurement given for modern Linux gettimeofday accuracy, but that function is subject to clock drift and user changes, so it's not appropriate for games anyway. I've seen clock_gettime be accurate to within several hundred nanoseconds usually, which is approaching the hardware limit. \$\endgroup\$
    – user744
    Dec 23, 2010 at 12:48

2 Answers 2


There's really two different questions here.

First is, how accurately can I measure the time? and the answer is incredibly accurately.

All modern CPUs (like, ~2000 onwards) come with high-resolution timers. On Windows, QueryPerformanceCounter is used to read these; on Linux and other POSIX systems, clock_gettime; on Mac OS X you can use mach_absolute_time or this wrapper that provides a basic POSIX-like clock_gettime wrapper around mach_absolute time.

These timers provide counters measured in nanoseconds, and the practical resolution is usually measured in microseconds. These clocks are also monotonic, meaning they should not go backwards, even if the user adjusts their clock or you're on a multicore CPU system, although there have been buggy BIOSs that caused this for some chips.

The second question is how quickly can I respond to events? and the answer here is much more depressing.

PC operating systems use preemptive multitasking, which means how much time your program gets is completely under the purview of the OS. When you sleep(10ms), that's a suggestion to the OS. It's rarely perfect, but usually it'll do its best, and you'll wake up sometime within the next 9.9 to 10.1 milliseconds. Sometimes though, it might be 15. Sometimes, if the system is under heavy load, it might be 10000. If an interrupt or signal occurs, it might be 1ms. This is why we have to jump through hoops to get truly stable timesteps in games.

Just knowing the time within 1ms precision? No problem. But relying on game logic that requires more precision than 1ms? That's a tricky business, and probably not appropriate for anything today.

  • \$\begingroup\$ There's a third question to consider here: how long can lag times realistically be before the player notices? Generally what matters to most players isn't the clock speed, so much as the framerate. \$\endgroup\$ Dec 23, 2010 at 20:20
  • \$\begingroup\$ Ian: What usually ends up being a problem is frequency interference from e.g. a 60Hz display update and a 29Hz game logic update, which usually is an issue of precision, either in the clock used or the sleep interval. Once you have dealt with that (via interpolation or whatever), anything ~20fps and up feels "okay". \$\endgroup\$
    – user744
    Dec 23, 2010 at 22:41
  • \$\begingroup\$ Ian: The other common problem - probably what you're calling "lag" - is due to double/triple buffering patterns on display and input, and is really outside the scope of this question. \$\endgroup\$
    – user744
    Dec 23, 2010 at 22:42
  • \$\begingroup\$ Never sleep. You should busy wait. \$\endgroup\$
    – bobobobo
    Dec 25, 2010 at 10:49
  • 2
    \$\begingroup\$ Busy waiting burns CPU like crazy and most games are GPU bound, not CPU bound. Sleeping until slightly before you want and then busy waiting up to that point can be acceptable, but busy waiting damages hardware, wastes electricity, makes other applications unusable, and still doesn't stop the OS from forcing you into the background. \$\endgroup\$
    – user744
    Dec 25, 2010 at 12:58

It depends.

As far as I'm concerned a game has a time unit of 16.66667ms (1/60 seconds).

Other than synchronizing framerate with the display, I don't need a concept of real-time except how much to idle at the end of a frame before rendering the next one.

I use a high performance counter there though (and microseconds!), because if there only is 1.45 ms left in the frame before the next one should be rendered, I don't want it to wait 2ms!


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .