Messages in this thread |  | | From | "Ulrich Windl" <> | Date | Thu, 31 Oct 1996 08:57:21 +0100 | Subject | time warps, I despair |
| |
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 offset
PPS/anomaly.tar.gz contains two PostScript files; one with the offset, and one with the frequency correction that xntpd (3.5.87.2) 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
|  |