Re: gettimeofday resolution seriously degraded in test9

[john stultz]

On Mon, 2003-10-27 at 15:44, Joe Korty wrote:
> [ 2nd posting, the first seems to have been lost ]
> 
> Linus,
>  This bit of -test9 code reduces the resolution of gettimeofday(2) from
> 1 microsecond to 1 millisecond whenever a negative time adjustment is
> in progress.  This seriously damages efforts to measure time intervals
> accurately with gettimeofday.  Please consider backing it out.
> 
> Joe
> 
> 
> diff -Nura linux-2.6.0-test8/arch/i386/kernel/time.c linux-2.6.0-test9/arch/i386/kernel/time.c
> --- linux-2.6.0-test8/arch/i386/kernel/time.c	2003-10-17 17:43:11.000000000 -0400
> +++ linux-2.6.0-test9/arch/i386/kernel/time.c	2003-10-25 14:43:37.000000000 -0400
> @@ -104,6 +104,15 @@
>  		lost = jiffies - wall_jiffies;
>  		if (lost)
>  			usec += lost * (1000000 / HZ);
> +
> +		/*
> +		 * If time_adjust is negative then NTP is slowing the clock
> +		 * so make sure not to go into next possible interval.
> +		 * Better to lose some accuracy than have time go backwards..
> +		 */
> +		if (unlikely(time_adjust < 0) && usec > tickadj)
> +			usec = tickadj;
> +
>  		sec = xtime.tv_sec;
>  		usec += (xtime.tv_nsec / 1000);
>  	} while (read_seqretry(&xtime_lock, seq));
> 

Hmm. This is the stair-step effect of capping time for NTP adjustments.
The side effect was expected, but I didn't figure it would be so drastic
as NTP adjustments are supposedly limited to 10%. Do you not see time
inconsistencies when running without this patch?

Stephen, any thoughts?  

thanks
-john


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/