Re: a faster way to gettimeofday?

[Jamie Lokier <lk@tantalophile.demon.co.uk>]

OBATA Noboru wrote:
> I'm running verification program for 18 hours, but the userland
> gettimeofday still synchronizes with the actual system call.
> 
>   :
>   :
>   sys: 1015885532.519445              <- system call
>   usr: 1015885532.519444 (-0.000001)  <- userland (difference in seconds)
>   sys: 1015885533.029344
>   usr: 1015885533.029344 (+0.000000)
>   sys: 1015885533.539446
>   usr: 1015885533.539445 (-0.000001)
>   :
>   :
> 
> Yes, it is just for fun...  Enjoy!

I was just thinking that I'd expect to see more drift, as in labs it is
really quite difficult to keep _different_ computers synchronised.
Thermal and/or power variation causes the clock frequencies to change,
just a little but enough that <1ppm over 18 hours would be improbable.
I've seen graphs in which night and day, even in an environmentally
regulated lab, show up.

But then I realised that the CPU clock and the PIT chip (which provides
the 100HZ tick) are sometimes derived from the same clock source anyway,
so the drift would be as good as the calibration.  And if they weren't,
they might will be physically close and so tend to drift together.

If you run NTP (synchronisation with atomic clock standards over the
network), you get really good real world clock times.  It continually
adjust gettimeofday() but not the rdtsc clock.  That may highlight any
drift due to thermal effects in the PC.

I would guess you're not running NTP?

cheers,
-- Jamie