Slackware 14.0

Hi: the time in my computer is always lagging exactly 3 hours. I set the right time but in a very short time it is lagging again. What can be the cause?

Since you're exactly 3 hours behind UTC, my guess is that it has something to do with that. Are you dual booting? Also, how are you setting the time?

I'd suggest using timeconfig to make sure that your timezone is correct. Then, make sure the clock is set to the proper local time. Once you've done that, use hwclock to save it to the hardware clock.

If your hardware clock uses UTC:

/sbin/hwclock --utc --systohc

If your hardware clock uses local time:

/sbin/hwclock --localtime --systohc

If you happen to be dual booting, the other operating system might have a different idea about whether you are using local time or UTC. If that is the case, and if it is set to synchronize from a network clock source, that could also lead to a 3 hour offset. Similarly, a wrong timezone setting on Linux combined with network time sync could lead to the 3 hour offset whenever the sync occurs.

I use dual booting but seldom boot the other OS. So, this can't be the cause. Also, the clock must be synchronized to some external source, and this is what I do not understand. I do not use ntpd or other network time service.

Another thing is that when in London it is, say 11pm, in my city it is 8pm. But I have 5pm! Just the same lag but opposite sign. It surely is a coincidence.

The actual UTC time is not relevant. If your hardware clock is set to local time (8 pm), but the system is configured to think that the hardware clock represents UTC, you'll be lagging by 3 hours.

Did you try reconfiguring and then saving the time to the hardware clock?

Yes, I did. Now I'll have to wait at least a day to be sure the clock is well. But why am I connected to an external source? Running 'ps -e|grep ntp' gives nothing. Maybe the GUI runs some network time service?

You might not be syncing to any external source. The example I gave where the hardware clock holds localtime but the system thinks that the hardware clock holds UTC would cause a 3 hour lag for your timezone whenever the hardware clock is fetched.

Hope it works. Good luck!

3 members found this post helpful.

Thank you very much.

In order to synchronize system clock and hardware clock, both must be set to the same time.

In this article,, I found these instructions:
Ntp is used to synchronize your computer to an external source which is in turn synchronized to an atomic clock at a research facility. It helps to overcome any creeping errors in time reporting due to hardware issues that are too technical for me to describe.

I ran timeconfig to set the time zone to my time zone, then date to set the time and 'hwclock --localtime --systohc'. Now I am periodically running 'hwclock ; date' to see which one of the clocks is lagging, if it is. It is possible that the time zone was wrong. It's the only possible explanation.

The timezone must have been wrong, because after running timeconfig the problem never occurred again. Now the system time is always correct, within the accuracy of the hardware clock.

If you are dual booting with Windows do NOT set your hardware clock to UTC.
Use localtime. Slackware will not add by default server entries to your
/etc/ntp.conf file, you must add them yourself:

Take in care ntp daemon will not correct automatically your time if the delay
is big, so you must stop it:

set the time with ntpdate:

and restart it:

Now I am not using Slackware I don't remember if some rc file runs hwclock at
shut down. You can check it doing:

If it doesn't you can add some of the hwclock commands explained by Patrick to
rc.local_shutdown

In the case of using Windows more than Linux (not your case) you should not use
ntpd and let Windows set the time.

Take in care that an old CMOS battery could be the cause of the problem.

Walter

1 members found this post helpful.

I suppose Windows connects itself to external sources on a periodic basis. How can this interfere with ntpd?

Windows does do what they call "Internet time" periodically to keep the clock(s) up to date. So, you might want to double-check your time zone settings in Windows and make sure it's correct.

Daylight time is coming soon (it's 10 March in the US) and your Linux system, if it's running, will switch the time. If you then boot Windows, it'll switch the time again, then you get back into Linux and your clock is all screwed up. Best solution I've found is to turn off the automatic daylight time adjustment in Windows. Other best solution is install Windows in VirtualBox (or some other virtual machine software) and you won't have the problem (Windows can't fiddle with the hardware in VirtualBox, but turn off the automatic daylight time adjustment anyway).

You're right, I didn't explain it correctly.

It's not exactly about using ntpd but using UTC time (like Patrick explained). Windows doesn't support UTC bios time, it will save your localtime to bios clock. When you reboot to a Linux configured to use UTC, ntpd won't sync because it can't handle big drifts.

I told you not use ntpd in that case because a common alternative is running ntpdate at boot time.

I think this is bad advice and will hit you every time you change from winter time to summer time and back.

PS: of course you have to use a certain registry setting under windows to make it assume the RTC time is in UTC