David Mosberger wrote: > > >>>>> On Wed, 24 Sep 2003 11:21:19 -0600 (MDT), Khalid Aziz <khalid@fc.hp.com> said: > > Khalid> do_gettimeofday() needs to account for lost ticks before > Khalid> returning current time and it fails to do > Khalid> that. do_gettimeofday() on other architectures compensate > Khalid> for lost ticks correctly. Due to this bug, if you repeatedly > Khalid> do clock_settime() immediately followed by clock_gettime() > Khalid> and compare the time returned by clock_gettime() to the time > Khalid> set by clock_settime(), you will eventually see clock going > Khalid> backwards. I am attaching a test program from POSIX > Khalid> testsuite at the end that exposes this bug. Run this test in > Khalid> a continuous loop that stops when test fails. > > This explanation doesn't sound right. See the "lost" variable in > gettimeoffset(). It's supposed to account for lost ticks. > > --david David, So it would seem. What would then explain clock going backwards? Here is what I see when the test fails: tpget=1037128357,995121000, tpset=1037128358,0 where tpget is what was returned by gettimeofday() and tpset is what was set by settimeofday(). Clock seems to have moved back by 4.879 msec. -- Khalid ==================================================================== Khalid Aziz Linux and Open Source Lab (970)898-9214 Hewlett-Packard khalid@hp.com Fort Collins, CO "The Linux kernel is subject to relentless development" - Alessandro Rubini - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Wed Sep 24 14:18:02 2003
This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:17 EST