From: Ulrich Drepper <drepper@cygnus.com> Date: 29 Aug 1999 09:56:37 -0700 I hope you suggest an implementation for a monotonic time implementation. Constraints are: The underlying OS will not notify each running program about a sudden clock change and itself does not provide a monotonic clock. TIME_MONOTONIC is optional; if the OS does not support TIME_MONOTONIC, then xtime_get (TIME_MONOTONIC | ...) returns an error indication. Kuhn's hope is that OS and C library suppliers can find their way to support TIME_MONOTONIC. I'm not an expert on GNU/Linux, but I believe that there's currently an awful way to get a TIME_MONOTONIC clock -- namely, read /proc/uptime. Clearly this could be improved by providing a more efficient way to get at the freerunning clock that's running inside the kernel. I expect that a small, well-thought-out patch to do this would be acceptable to the Linux kernel hackers. I expect other Unix kernels would be similar. I think about things like the time stamp counters found on many modern processors. But: - they are only found on modern processors, and therefore a generic implementation isn't possible Absolutely. - even if they are available, they might be useless if, as in the case of the Alpha, the counter range is too small That's a problem. (I wonder why the Alpha doesn't have a 64-bit clock?) Presumably on the Alpha one would have to fall back on a lower-resolution monotonic clock, e.g. the number of clock interrupts serviced by the kernel. As Kuhn mentions, there is certainly a need for a TIME_MONOTONIC in some applications. The question is whether this need is enough to justify inclusion in a standard API.