LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   Time lags by exactly 3 hours always. (http://www.linuxquestions.org/questions/slackware-14/time-lags-by-exactly-3-hours-always-4175451045/)

stf92 02-20-2013 11:30 PM

Time lags by exactly 3 hours always.
 
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?

volkerdi 02-21-2013 12:07 AM

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.

stf92 02-21-2013 12:12 AM

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.

volkerdi 02-21-2013 12:42 AM

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?

stf92 02-21-2013 12:46 AM

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?

volkerdi 02-21-2013 12:50 AM

Quote:

Originally Posted by stf92 (Post 4896466)
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!

stf92 02-21-2013 12:52 AM

Thank you very much.

bigrigdriver 02-21-2013 01:23 AM

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

In this article,, I found these instructions:
Quote:

Setting the system clock

To set the system clock under Linux, use the date command. As an example, to set the current time and date to July 31, 11:16pm, type ``date 07312316'' (note that the time is given in 24 hour notation). If you wanted to change the year as well, you could type ``date 073123161998''. To set the seconds as well, type ``date 07312316.30'' or ``date 073123161998.30''. To see what Linux thinks the current local time is, run date with no arguments.
Setting the hardware clock

To set the hardware clock, my favourite way is to set the system clock first, and then set the hardware clock to the current system clock by typing ``/sbin/hwclock --systohc'' (or ``/sbin/hwclock --systohc --utc'' if you are keeping the hardware clock in UTC). To see what the hardware clock is currently set to, run hwclock with no arguments. If the hardware clock is in UTC and you want to see the local equivalent, type ``/sbin/hwclock --utc''
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.

stf92 02-21-2013 01:31 AM

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.

stf92 02-28-2013 05:56 PM

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.

eloi 03-02-2013 06:18 AM

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:

Code:

server 2.ar.pool.ntp.org                iburst
server 0.south-america.pool.ntp.org        iburst
server 2.south-america.pool.ntp.org        iburst

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

Code:

# /etc/rc.d/rc.ntpd stop
set the time with ntpdate:

Code:

# ntpdate 2.ar.pool.ntp.org
and restart it:

Code:

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

Code:

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

Code:

# echo '/sbin/hwclock --localtime --systohc' >> /etc/rc.d/rc.local_shutdown

# chmod +x /etc/rc.d/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

stf92 03-03-2013 05:53 AM

Quote:

Originally Posted by eloi (Post 4903057)
In the case of using Windows more than Linux (not your case) you should not use
ntpd and let Windows set the time.

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

tronayne 03-03-2013 07:21 AM

Quote:

Originally Posted by stf92 (Post 4903636)
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).

eloi 03-04-2013 04:00 AM

Quote:

Originally Posted by stf92 (Post 4903636)
I suppose Windows connects itself to external sources on a periodic basis. How can this interfere with ntpd?

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.

Martinus2u 03-04-2013 06:30 AM

Quote:

Originally Posted by eloi (Post 4903057)
If you are dual booting with Windows do NOT set your hardware clock to UTC.
Use localtime.

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


All times are GMT -5. The time now is 01:34 AM.