Debian Lenny Severe time drift
 

I was running Debian Etch for a while and upgraded to Debian Lenny months ago. After the upgrade I began to notice that I was losing time pretty severely on the desktop clock (On the order of more than 1 second every minute!). After trying to troubleshoot it for a couple days I finally gave up and took the easy way out and added a crontab entry:where synctime.shWhich took care of the time drift because it updated the time every 5 minutes. I recently noticed an online game lagging exactly every 5 minutes and finally pinpointed it to this timekeeping script I wrote. I would like to fix the time drift issue on this PC properly now but have not found any helpful documentation online yet. If it helps, my motherboard is:

Foxconn A74MX-K

And I have not restarted the computer yet, but if I remember correctly from before, the clock is accurate on startup but then starts to drift immediately. So the amount of drift depends on how long the computer is on.

Any ideas on what could point me in the right direction? Thanks.

Looks like you are not running ntp, Network Time Protocol. In Debian, go into Synaptic, and search for NTP. Install that, and it will go out to time servers on the net and get and maintain the correct time on the system. If you have an intermittent connection, rather than an always-on one, you may also like to use ntpdate.

I have/had the same problem on my Ferrari laptop, I have gotten it down to under a minute a day using adjtimex which is in stable package repo. I gave up on ntp since I am not permanently connected to the interwebbienet thingamajig. My Bios/cmos hwclock has been stable so every now and then I run adjtimexconfig which takes 70 seconds or so and it is gradually getting my system clock to run more accurately.

I do have ntp installed which is why my script stops it in order to call ntpdate... so what you are saying is the same as what I was already using.

I have tried adding "iburst" to the end of the server argument in the ntp.conf file and have not yet seen any improvement. I'll have to check into the adjtimex that you recommend minrich. It's just that I do have an always on internet connection so I don't understand why this is happening in the first place...

I take your point, you are issuing commands to ntp, so you possibly have ntp on board, but it doesn't appear to be working (sorry to state the obvious!). Things to check:
1) Is ntp able to freely transit any firewalls;
2) Is ntp correctly configured (what time server, if any, is it using)
3) Is it *really* running? yes, I know you are issuing start commands, but is it genuinely starting and running properly? Issue command:

ps -ef | grep ntp

and you should get something like:

jim@bastion:~$ ps -ef | grep ntp
ntp 5248 1 0 Jan19 ? 00:00:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -u 108:112 -g
jim 22464 22444 0 13:59 pts/1 00:00:00 grep ntp
jim@bastion:~$

Also look in ntplogs and syslog to see if anything is showing up there...

#ps -ef | grep ntp
ntp 7648 1 0 07:02 ? 00:00:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -u 108:112 -g[/code]

The computer has been running for between 12 and 13 hours and has lost over 17 minutes. There is nothing in the syslog file which only contains information for about the last 12 hours. I don't know if there are any other ntp logs. Any other suggestions?

Just wondering, have you tried turning on the pc, check the bios clock, boot as far as the boot loader but don't select an OS to load... leave it a while, re-boot pc and check bios clock.

Like wise check the bios clock, boot the os (leave it to drift) and then check the bios clock against the drift in the OS.

This will at least prove its the os causing the problem, and not the rtc/motherboard. Reason I ask is that I had a similar problem, turned out the battery was on its way out and for some strange reason it was affecting the rtc even when the board was attached to live power.

No I have not. I can say that:
is about 8.5 minutes ahead of the system clock, which is now about 21 minutes behind the actual time. If I have some spare time I will try your suggestion, but it just doesn't feel like that should be the issue since it has been a problem for months.

Curious...OK, lets get down to the nitty-gritty :)

Can you post up your /etc/ntp.conf, so we can check that. Also, assuming that in that file, you are pointing at the timeservers:

server 1.debian.pool.ntp.org
server 2.debian.pool.ntp.org
server 3.debian.pool.ntp.org

can you attempt a ping to them (if you are pointing at others, then change your ping target accordingly). Post up the results of those pings as well.

It looks like ntp is up and running just fine, I'm beginning to think ts not able to communicate with its servers. A good suggestion about the BIOS clock, but the differences in BIOS and System clocks seem to point us away from that.

All of these ntp servers were in the Time and Date Settings that you can access through the Gnome clock. It must automatically update the ntp.conf file when you select them. I have tried it with them one at a time too.

I will switch it over to the debian timeservers to see if that helps. I am able to ping all 3 of them.

edit:

BTW the system time syncs fine when the system is booted or anytime I restarted ntp. After that it does not seem to attempt to resync.

Hmmm, curious. Your .conf file looks almost identical to mine, except for the "tinker panic 0".

In order to keep ntpd running you have to tell it not to panic if it gets a very large time offset. The ntp daemon will accept an offset of up to 1000 seconds by default. Anything over that and it will panic and stop.This is fixed by following line:

tinker panic 0

which is more commonly found on VM Guest OSs, where there is no BIOS clock and the guest will start up without any knowledge of the real time.

The 0 says “accept any offset” which means that if your machine is suspended for a long time, if it starts and finds a gets a very large offset it will continue to try to sort the timing regardless.

You shouldn't need this line, but equally, it shouldn't be doing any harm (?)


Try the different servers, and also try commenting out the "tinker" line. I admit to being close to my limit of knowledge here, but if we can fix this, perhaps we'll both learn something :)

Unfortunately the tinker line was just added yesterday in hopes that it would help. I thought maybe that ntp was giving up by the time it checked the time because the offset was so great. Can you tell me what shows up in your syslog to see how often your ntp logs information? I thought it odd that it shows data when it first starts up, but nothing after that. Granted I shut down my computer every night so it never has an opportunity to run again if it only tries every 24 hoursish. I do have a DVR running Knoppmyth on Arch Linux that I could try to compare logs to as well, but if you have any information handy it would be appreciated. Thanks.

adjtimex was what I needed. I printed out the information and where ticks is supposed to be near 10,000, mine was at something like 9,637. I adjusted it up to 10,000 and it now is gaining about 2 seconds every 12 hours. That's not bad, but I will have to tinker some more with the ticks and frequency to get it slightly more precise. It is much better than losing minutes on the hour, though. Thanks for the tip!

You are welcome

Now I'm puzzled! The system is on line (you say you run on-line games) but ntp doesn't keep it on time. It's great that adjtimex gets somewhere with the problem, but is that not simply covering up the real problem, which is that ntpd is failing to work?

Sorry to be a nay-sayer, but while you have stopped the problem occurring, I suspect the fix has affected the symptoms, not the cause.

If you have time, it may be worth running wireshark or similar and seeing what ntpd is doing on the network connection, I still think it may be trying to get out and failing....but as I said earlier, I am reaching the limits of my knowledge here, so take everything I say with a pinch of salt!