Re: gettimeofday resolution seriously degraded in test9

[Stephen Hemminger <shemminger@osdl.org>]

On Tue, 28 Oct 2003 12:55:58 +0100
Gabriel Paubert <paubert@iram.es> wrote:

> On Mon, Oct 27, 2003 at 05:17:38PM -0800, Stephen Hemminger wrote:
> > Arghh... the patch was being way more agressive than necessary.  
> > tickadj which limits NTP is always 1 (for HZ=1000) so NTP will change
> > at most 1 us per clock tick.  This meant we only had to stop time
> > for the last us of the interval.
> 
> Hmm, I still don't like it. What does it do to timestamping in
> interrupts in the kernel, especially when there is a burst of
> interrupts?
> 
> If I read it correctly, the time will be frozen between the time
> the timer interrupt should have arrived and the time it is processed.
> So the last micosecond of the interval could extend well into the next
> interval, or do I miss something (I also suspect that it could
> make PPSKit behave strangely for this reason)?

The original problem all this is solving is that when NTP is slowing the clock
there existed real cases where time appeared to go backwards. Assuming NTP was
slowing the clock, then it would update the xtime by 999us at the next timer interrupt.
If a program read time three times:

A:	    xtime = t0
B: A+1000   xtime = t0 + 1000
C: B+1	    xtime = t0 + 999

To behave correctly C > B > A; but we were returning C < B

The code does have bug if we are losing clock interrupts.  The test for
lost interrupts needs to be after the interval clamp.

This should work better. Patch against 2.6.0-test9

diff -Nru a/arch/i386/kernel/time.c b/arch/i386/kernel/time.c
--- a/arch/i386/kernel/time.c	Tue Oct 28 10:08:52 2003
+++ b/arch/i386/kernel/time.c	Tue Oct 28 10:08:52 2003
@@ -94,6 +94,7 @@
 {
 	unsigned long seq;
 	unsigned long usec, sec;
+	unsigned long max_ntp_tick = tick_usec - tickadj;
 
 	do {
 		unsigned long lost;
@@ -102,16 +103,20 @@
 
 		usec = cur_timer->get_offset();
 		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;
+		if (unlikely(time_adjust < 0)) {
+			usec = min(usec, max_ntp_tick);
+
+			if (lost)
+				usec += lost * max_ntp_tick;
+		} 
+		else if (unlikely(lost))
+			usec += lost * tick_usec;
 
 		sec = xtime.tv_sec;
 		usec += (xtime.tv_nsec / 1000);