[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