Messages in this thread | | | Date | Tue, 12 Mar 2002 13:06:35 +0000 | From | Jamie Lokier <> | Subject | Re: 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?
cheers, -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |