Re: [PATCH] do_gettimeofday() fails to compensate for lost ticks

From: Khalid Aziz <khalid_aziz_at_hp.com>
Date: 2003-09-25 04:17:41
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.html
Received on Wed Sep 24 14:18:02 2003

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:17 EST