A Matter of Time

I spent an awful lot of time earlier this week looking for a way to get the time of day to better than Solaris' default 10 millisecond resolution. There were plenty of ways to get relative times at resolutions pretty darn close to a nanosecond, but no time of day. This strikes me as a giant void in operating system time services. Surely I'm not the only person who's wanted this before now.

Of course I'm not really the person who wants it. It's simply a requirement that the software has to meet. I wouldn't levy a better than 10 microsecond accuracy requirement on software timestamps for a soft real time system. As far as I'm concerned, down to the millisecond is usually good enough. But I'm not the one who gets to decide these things; I just have to make them happen.

I can think of several ways to do it. I just don't like any of them. They all have significant drawbacks. The whole task is complicated by the need to synchronize two separate pieces to the same high-resolution time source.

The easiest solution, but also the one most likely to have negative consequences, is to simply change the system clock resolution to the required 10 microseconds. The obvious negative to this approach is the fact that the system will have to process 1000 times more clock interrupts. This is not particularly conducive to performance.

The second is to write software for the two separate pieces to read the high-resolution time source directly. Aside from the negative of having to write JNI to access the time source from within the Java application, there's the high probability that the time source does not behave nicely when trying to access it from two separate processes.

Another is to create a separate service to manage the time source for the entire system. That would entail inter-process communication, which would probably introduce unacceptable delays in acquiring the time. This approach would probably not meet the accuracy requirement in the first place.

Analogous to the last is folding the second synchronization piece into the operational software, but that would require granting its user privileges it probably ought not to have. If it's not deemed an unacceptable security risk, this is probably the approach I'll have to take.

Making a computer dance to a specific tune is not always fun and games. Sometimes there are real problems to be solved. Most of the time, a solution is fairly evident. This is not one of those times.