So there I was thinking I had my time problems sorted. But then I found out about this new little program called adjtimex that allows the exploration of system time variables. "Super!" I thought, "It will let me get to grips with this time thing."

As it installed itself, it ran a programme called adjtimexconfig. This seemed like a sensible thing. It wasn't.

Within minutes, I noticed, through continually doing ntpq -p, that the offset, i.e. the discrepancy between my local clock and internet time servers, was getting bigger and bigger. Eventually, no synchronising was taking place and ntpd was looking at only the local system clock as a time reference. On top of that, I could see that my my computer clock visibly losing time. What on earth was going on?

As it turns out, adjtimexconfig, had set the 'tick' variable to 9,769 as opposed to 10,000 as it is supposed to be.

The first thing I did was to discover what a tick actually is. Well, a tick is just that the 'tick' of a clock. Linux assumes that there are 10,000 µseconds between each tick, but sometimes there may be more and sometimes fewer. By adjusting 'tick' you can adjust the clock drift in microsecond increments. For finer tuning of the clock, you can use the frequency variable. One tick is equal to 6,553,600 frequency units.

One thing is to use adjtimex --compare to see what it recommends you set the time to. Every time I tried it the output is different. Here is one example:

cmos time     system-cmos  error_ppm   tick      freq    tick      freq
1143017967     0.003235
1143017976     0.553166    54993.1  10001  -3203509
1143017986     0.003725   -54944.1  10001  -3203509   10549   6239316
1143017995     0.140299    13657.4  10001  -3203509    9863   6141728
1143018005     0.004241   -13605.8  10001  -3203509   10136   3730803
1143018014     0.131212    12697.1  10001  -3203509    9873   3540103
1143018023     0.826183    69497.1  10001  -3203509    9305   3539591
1143018033     0.005013   -82117.0  10001  -3203509   10821   4464803

As you can see, the recommended tick values are all over the place and every time the utility is run they are different. I conclude that either adjtimex is not working properly, or that time on the laptop is very unstable (Doesn't that sound like something from Doctor Who?).

I used tickadj to set tick back to 10,000.

tickadj 10000

Then I restarted ntpd which, no longer having this crazily high clock drift, was able to synchronise with remote servers. Once, ntpd and sync'd, it was able to create the ntp.drift file which indicates how much the clock is drifting. Then using a script from this page I could recalculate what my 'tick' value should be:

echo "scale=7; `tickadj`; drift=`cat /var/lib/ntp/ntp.drift`;
t=tick*(1+(drift)/2^20)+0.5; scale=0;t/1" | bc

This suggested 10001, which I set it too. For a while, the offsets I was seeing when I do ntpq -p were smaller than they have been, but always in the teens. Recently, they've sprung back up to the high twenties. The ntp.drift file is reporting drift is 29.353. The day before writing this it has a value of around -50.

I conclude that the laptop clock is a bit crazy. Probably ticks are being dropped or lost. Another problem with laptops generally, and most probably this one in particular, are the varying processor speeds.

These problems have led me to suspect that laptop time adjustment must be treated cautiously. I'm going to see how things develop over the next week or so, but generally, I suspect ntpd needs to be turned off before a 'suspend'. There are also issues of the laptop going on and offline as they are apt to do. Perhaps ntpd should stop running when the laptop goes offline.

One last thing. There is an interesting page here from David Carlton who was using cron to adjust the tick value twice a day to keep his system keeping good time.

Save/Share: Stumble It!  Subscribe Share on Facebook Digg it Reddit Delicious