Unruh <[EMAIL PROTECTED]> wrote: >After I collect more data on steady state, I will rerun startups both with >no drift file and a bad drift file to see how fast the convergence is with >4.2.4.
Hi, On recent Linux kernels, I think the drift file is always bad after reboot. HZ=100, no dynamic ticks aka tickless system (CONFIG_NO_HZ not set). I think I even tried with a kernel command line option lpj= but it didn't help. If the system is rebooted, ntpd stabilizes to a new different drift value. With a bad or missing drift file, time set with ntpdate, ntpd can soon take the offset to a 100 or 200 ms error for a long time. If you are using Linux and are experimenting with these, please try something like this which has given me good results (a coarse calibration of the drift file during boot before starting ntpd): #!/bin/sh DRIFTFILE=/etc/ntp/drift NTPSERVER=ip.address.of.a.good.nearby.ntp.server TIME=100 # remember to stop ntpd first if running # reset frequency offset to zero adjtimex -f 0 # calibrate clock rate during $TIME seconds ntpdate -sb $NTPSERVER sleep $TIME ADJUST=$(ntpdate -b $NTPSERVER | sed 's/.*offset \(.*\) sec.*/\1/') # ntpdate adjusted $ADJUST seconds FREQUENCY=$(echo "scale=3; $ADJUST * 1000000 / $TIME" | bc) # reset the drift file and start ntpd echo $FREQUENCY > $DRIFTFILE /etc/rc.d/rc.ntpd start _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
