Messages in this thread | | | Subject | Re: gettimeofday resolution seriously degraded in test9 | From | john stultz <> | Date | 27 Oct 2003 16:29:26 -0800 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |