time warps, I despair

Ulrich Windl (ulrich.windl@rz.uni-regensburg.de)
Thu, 31 Oct 1996 08:57:21 +0100

I'm working on the Linux clock code. Some long time ago I experienced
odd time warps I could not explain, and nobody else had a good idea,
except that the Linux kernel was broken.

Now I examined all the code, especially the NTP specific parts I
validated twice, but found nothing. Then I began to comment-out all
suspicious parts that might cause it (e.g. updating the CMOS clock).
Still no success. I suspect some code outside of the timing code, or
maybe still the Pentium fast timeoffset.

I also examined that code, but the only thing I found is that the
computed offset sometimes exceeds tick (10000) by values between 1
and 10, but that is clamped and not the visible effect. Another thing
is that the calibration part uses elapsed Pentium cycles and elapsed
jiffies and divides them to estimate the cycles per jiffy.
Unfortunately both values seem to start at a different time so that
the quotient might wander a bit in the beginning, but that's also not
the effect.

So what's the effect? From time to time the clock offset jumps for
some amount always less or equal to what's worth one tick (i.e.
offset jumps around from -5ms to 5ms when synchronized). To thos who
might get an idea when they see the pattern, I put two files on a FTP
server (pcphy4.physik.uni-regensburg.de):

PPS/sawtooth.ps.gz uses samples every 64 seconds and shows just the

PPS/anomaly.tar.gz contains two PostScript files; one with the
offset, and one with the frequency correction that xntpd (
applied to compensate the error. These samples use 16 seconds for the
polling interval.

As all is not more than 20kB, maybe some people can have a look at it
and tell me their theories...

My PC has an Adaptec 2940, an Intel Triton/VX chipset, a PS/2 mouse, a P100 and
32MB RAM. During measuring the system was practically idle.

Ulrich Windl