[lkml]   [2002]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: a faster way to gettimeofday?
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?

-- Jamie
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:24    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean