Sorry for the delay, a lot of tests going on in the meantime... Am 12.01.2011 18:54, schrieb unruh: > On 2011-01-12, Heiko Gerstung <heiko.removethistext.gerst...@meinberg.de> > wrote: >> Just an addition: >> >> The peerstats file shows the nearly the same time jumps at exactly the same >> time. I am still wondering if this is NTP or the >> Kernel ... > > Probably the hardware. But what kind of kernel are you running? > Tickless? Or is this virtual OS? No, it's a standard Linux 2.6.33 (also tried 2.6.37, same problem) on real hardware (Embedded i386 compatible CPU). I tried HZ=250, HZ=100 and HZ=1000 (tickless does not seem to be something I want to try out....). The problem exists with all three different HZ settings, but the interval changes. The anomalies happen more often with the HZ=1000 settings and less often with the HZ=100 setting.
> Remember, all the kernel has to figure > out the time is its own interenal counters/oscillators. If they go out, > or skip, then suddenly your time is out. The time does not seem to be > jumping (ie is not going from 2us to 2ms between one reading and the > next) but rather seems suddenly to be drifting fast-- as if the CPU > suddenly got hot. Mmmh, the polling cycle I use is 8s (patched ntpd), and if you look at this sample sequence ...: >>> 55571 1286.037 0.000000000 -85.118 0.000001922 0.000329 3 >>> 55571 1294.037 -0.000228000 -85.230 0.000080528 0.039362 3 >>> 55571 1302.037 0.000035000 -85.213 0.000119531 0.037312 3 ... you see that it goes from 0us to -228us and back to +35us. > Ie, is this correlated with a sudden burst of activity > of the computer? I did some testing and fired up dd to max out CPU utilization (dd if=/dev/zero of=/dev/null) as well as used some bash scripting to keep it busy ( while true; do echo $((13**9)) > /dev/null ; done), both results in 100% CPU utilization, but that did not do anything with the offset reported by ntpd. I kept that running for a couple of minutes, but no spike or anything. I also did not find anything unique/unusual in the system log with a timestamp near the "spikes". Will have to continue to look into the kernel, I guess. Next test: Running NTPD with "disable ntp" to see if the anomaly still shows up, independent of ntpd's actions. My suspicion is that there is something wrong with the kernel timing, which does not affect all platforms and hardware. Best Regards, Heiko _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
