Scott’s Weblog

Monotonic time in Mac OS X

January 19th, 2009

Turns out calculating elapsed times in Mac OS X is a pain. Why not just use gettimeofday(2)? If you’re trying to calculate a time period between two events, you should be able to call gettimeofday(2) before and after, subtract the results, and you’d have an elapsed time, right? Well, almost – but gettimeofday(2) is based on the “wall clock”, so if the time changes between calls to gettimeofday(2) – e.g. daylight savings starts, leap seconds get added, etc – then the elapsed time will be wrong. This also leads to fun when the time is adjusted backwards between calls.

Enter the concept of monotonic time. Monotonic time is a time that increases, well, monotonically from an arbitrary reference point. It is not based on the wall clock, so it’s pretty useless for saying “this event happened at this point in time”, but it is very useful for calculating the time difference between two events, as the clock source won’t ever change between reads.

POSIX defines a nice way of getting times from arbitrary clock sources – clock_gettime(2). You can ask clock_gettime(2) for a time from a number of different clocks. For example, CLOCK_REALTIME will give you the wall time. Linux implements a number of clock sources, including the CLOCK_MONOTONIC source which gives you a nice monotonic time to use for measuring time differences reliably.

Unfortunately Mac OS X (at least 10.5) doesn’t implement clock_gettime(2), which means there’s no simple (read standard) way to get a monotonic time on Mac OS X. As always though, there is a solution.

<mach/mach_time.h> exports the function mach_absolute_time(). This function returns a CPU dependent time, which can, after a bit of magic, be used as a monotonic time. There is a good discussion on the Apple message boards (which you’ll have to follow through to get the whole story) and a Technical Note which are interesting references. Unfortunately it’s not mentioned in any man pages though.

As it turns out, the absolute time units returned by mach_absolute_time() are not affected by CPU power saving, sleeping, etc. mach_absolute_time() is the base function from which all higher level timer related functions are implemented, for example, gettimeofday(2). So, how do we use mach_absolute_time() as a monotonic clock? Well, calling mach_absolute_time() before and after the event we want to measure is a start. Then we need to convert the difference to something useful. The return value from mach_absolute_time() can be converted to a more useful time unit by multiplying it by the fraction returned by mach_timebase_info(). This fraction will convert the absolute time into a time in nanoseconds. Armed with this, we can write some code that converts a difference into the familiar struct timespec:

#include <mach/mach_time.h>
#include <time.h>
#include <stdio.h>

void mach_absolute_difference(uint64_t end, uint64_t start, struct timespec *tp) {
        uint64_t difference = end - start;
        static mach_timebase_info_data_t info = {0,0};

        if (info.denom == 0)
                mach_timebase_info(&info);

        uint64_t elapsednano = difference * (info.numer / info.denom);

        tp->tv_sec = elapsednano * 1e-9;
        tp->tv_nsec = elapsednano - (tp->tv_sec * 1e9);
}

int main(int argc, char *argv[]) {
        uint64_t start,end;
        struct timespec tp;
        start = mach_absolute_time();
        sleep(1);
        end = mach_absolute_time();
        mach_absolute_difference(end, start, &tp);
        printf("%lu seconds, %lu nanoseconds\n", tp.tv_sec, tp.tv_nsec);
        return 0;
}

Running this code produces the output:

kenshin:~ scottr$ make time
cc     time.c   -o time
kenshin:~ scottr$ ./time
1 seconds, 130951 nanoseconds

The fraction returned by mach_timebase_info() does not appear to change as the processor scales, at least on this Intel mac I’ve done some rudimentary tests to make sure that time does increase monotonically when the system clock changes, when the machine goes to sleep, etc, and it all seems to work fine. If anyone out there with a Mac wants to test these theories please do and please get back to me with your results.

It’s a pity that Apple didn’t decide to implement clock_gettime(2) themselves. I guess we can hope that in a later version of Mac OS X it will be implemented but until then we apear to be stuck with this workaround.

Entry Filed under: General