Re: strange nonmonotonic behavior of gettimeoftheday -- seen

[george anzinger]

"Richard B. Johnson" wrote:
> 
> On Fri, 2 Mar 2001, george anzinger wrote:
> 
> > "Richard B. Johnson" wrote:
> 
~snip~

> > > Note that two subsequent calls to gettimeofday() must not return the
> > > same time even if your CPU runs infinitely fast. I haven't seen any
> > > kernel in the past few years that fails this test.
> >
> > Oh!  With only micro second resolution how is this avoided?  The only
> > "legal" thing to do to avoid this is for the fast boxes to loop until
> > the requirement is satisfied.  Is this really done?
> >
> > George
> >
> 
> Yes and no. It takes microseconds to call the kernel for anything (time
> getpid() ), so it seldom loops. All the kernel has to do is remember
> the last value returned. If the time isn't past that time yet, bump
> that value and return it instead of waiting.
> 
Well, "has to do" and "does" are two different animals.  My reading of
the code shows that it does not.  I have a bit of code that does
gettimeofday() calls as fast as possible and on some boxes (ix86) have
seen the difference as low as 1 micro second.  It is not beyond
imagination that a box might return the same time two times in a row
given the processors performance increases we are seeing.  I, for one,
don't find this objectionable.  I WILL take exception to time running
backward, however.  (I don't see how this is avoided on the leap second
delete, but I have just started looking at this issue.)  As to returning
a time in the future as you suggest, I think this is a bad policy.  If
the box can actually do two gettimeofdays in one micro second or less,
it SHOULD return the same time (given the resolution can not resolve the
difference).  If this becomes an issue, and it will, those that care
should use the clock_gettime() call which should return time in nano
seconds.  This is part of the POSIX standard code for which we are
working on at:

http://sourceforge.net/projects/high-res-timers/

George