Re: Time stamp resolution

[David Boyce]

At 03:12 PM 1/24/2005, Jason Pearce wrote:
> Is it safe to assume that two files, generated in sequential order, will 
> always have increasing time stamps?

Yes, within the granularity of the local OS and filesystem. You should read 
up on the .LOW_RESOLUTION_TIME target also. Most Unix systems track time 
with better granularity than they allow setting and getting it (this is 
remarkably lame but has persisted for some reason I don't know). Windows 
claims to track file timestamps in 100-nanosecond increments (I've seen 
these referred to as "clunks" sometimes), and provides API calls for 
getting that data. Unix is slightly hobbled by historical practice; the 
stat() system call is defined to return file times in increments of 1 
second and that can't be changed for both compatibility and conformance 
reasons. But under the covers, both Linux and Solaris (I haven't checked 
other systems) slip additional fields into the stat structure. Solaris 
tracks a granularity of 1 nanosecond within its hidden field (though I 
strongly suspect current hardware can't actually do nanosecond resolution - 
they're just leaving room for Moore's Law). Linux does something similar 
but I don't recall the details. I think maybe they only track microseconds. 
In any case, neither (AFAIK) provides an official API for getting this 
"high resolution time"; you have to look into /usr/include/sys/stat.h and 
figure out how to get it. Worse, there's absolutely no way to set it 
explicitly. This is the problem addressed by .LOW_RESOLUTION_TIME.

None of that is directly applicable to your problem, it's just for 
background. Your problem seems more likely related to inter-system 
synchronization problems as someone else suggested, or some other config 
problem.

-dsb