ntp problem

[HTRon]

I'm having a problem with suse linux 10 sp1. this is running on a vmware virtual machine.

I have ntp set up and running. Every couple/few weeks, it seems to lose contact with the ntpserver or something, and the clock jumps ahead around 45 minutes!

my xntp shows v4.2.0 - is there a way (or need) to update that?

any other ideas why this would happen?

(I'm not a linux expert myself, but I do have access to a couple of linux people locally, though they are not fluent in suse.)

Thanks,
Ron

[gogalthorp]

Is this running all the time on a server? What is the Host? Is the CPU frequency scaled. Are both the Host and guest using UTC or Local as a base time?

Usually ntp only runs at boot.

Suse 10 sp1 is the commercial Novell version. The curren2 revision is sp 3

[HTRon]

ntp is running all the time, if that's what you mean. host and guest are local time. I don't understand the cpu question, sorry.

ntp starts at boot, and then keeps running to keep the time in sync. we see in the logs where it updates the time, but then suddenly it says the time is more than 1000 seconds off so it can't correct. interestingly, this happened on august 21st, july 22nd, and june 22nd.............maybe ntp only runs for 30 days or something???

I did find that sp3 is current, and it has 4.2.4 of ntp, so we're going to load that.

thanks for your reply!

[gogalthorp]

NTP only connects at startup and syncs the hardware clock, from then on time is kept by the OS internal clock. Generally the hardware clock is not consulted again.

The OS clock uses the cpu freq as a base time reference if the CPU freq changes in the host the guest does not know it and the guest clock runs fast. So if you have frequency scaling turned on it can lead to the guest having the wrong time.

Note that the NTP reference site clock the hard ware clock and the internal OS clock and the guest OS clock are 4 different clocks.

The Guest OS reference time (Local/UTC) should agree with the hosts.

Generally Windows assumes the hardware clock is set to the local time but Linux assumes that the HWC is set to UTC.

[Segfault]

NTP is running all the time. It syncs with an external NTP server and keeps OS clock correct. It uses very little increments to correct the clock, big jump would be a security risk. After NTP learns what your CPU clock drift is it will increase the external server query interval.
NTP can be configured to set the clock at startup regardless how big the difference is.

Edit: There used to be vmware problems with clock, I was under impression this is fixed by now. Maybe not. Google.

[HTRon]

NTP only connects at startup and syncs the hardware clock, from then on time is kept by the OS internal clock. Generally the hardware clock is not consulted again.

The OS clock uses the cpu freq as a base time reference if the CPU freq changes in the host the guest does not know it and the guest clock runs fast. So if you have frequency scaling turned on it can lead to the guest having the wrong time.

Note that the NTP reference site clock the hard ware clock and the internal OS clock and the guest OS clock are 4 different clocks.

The Guest OS reference time (Local/UTC) should agree with the hosts.

Generally Windows assumes the hardware clock is set to the local time but Linux assumes that the HWC is set to UTC.

yeah, ntp is running (if you set it up) to keep the clock in sync...


console-drh:~ # tail /var/log/ntp
25 Aug 07:46:58 ntpd[28710]: synchronized to 155.139.59.11, stratum 4
25 Aug 07:56:37 ntpd[28710]: time reset -0.467719 s
25 Aug 08:01:57 ntpd[28710]: synchronized to 155.139.59.11, stratum 4
25 Aug 08:11:38 ntpd[28710]: time reset -0.441267 s
25 Aug 08:17:00 ntpd[28710]: synchronized to 155.139.67.11, stratum 3
25 Aug 08:18:06 ntpd[28710]: synchronized to 155.139.59.11, stratum 4
25 Aug 08:26:47 ntpd[28710]: time reset -0.529723 s
25 Aug 08:32:09 ntpd[28710]: synchronized to 155.139.59.11, stratum 4
25 Aug 08:41:45 ntpd[28710]: time reset -0.454837 s
25 Aug 08:47:07 ntpd[28710]: synchronized to 155.139.59.11, stratum 4

[HTRon]

NTP is running all the time. It syncs with an external NTP server and keeps OS clock correct. It uses very little increments to correct the clock, big jump would be a security risk. After NTP learns what your CPU clock drift is it will increase the external server query interval.
NTP can be configured to set the clock at startup regardless how big the difference is.

Edit: There used to be vmware problems with clock, I was under impression this is fixed by now. Maybe not. Google.

I agree about the vmware/clock potential problem, though that should't come into play if ntp is keeping the clock in sync, I wouldn't think? unless it causes a large jump! just seems strange that about every 30 days this problem occurs...(saw it jun 22, jul 22, and aug 21...because july had 31 days...)

[linuxforever]

Indeed your NTP program keeps your OS clock in sync with the NTP-server clock.
This OS clock is linked to the hardware clock of your motherboard.
You can set them both with the date/year in the cmos setup.
However this hardware clock insn't that reliable.
This means that most hardware clocks will come off track always.

To solve this problem you can connect to a NTP server.
In the setup you can select a pool of NTP servers in your country, or a specific one.
But in another country is also possible.
If you use windows xp for example it is standard connected to a microsoft NTP server.
But you can also select another one.

It is a good thing to use a NTP server.
It keeps your OS clock to the second exact.
Indeed will the NTP program be constantly running and correcting.
If it should do it only at boot time it would make no sense.
Think of a pc that's running all days.

The NTP (client) program normally should give no problem.
So I think it might be vmware related.

[Segfault]

Indeed your NTP program keeps your OS clock in sync with the NTP-server clock.
This OS clock is linked to the hardware clock of your motherboard.
You can set them both with the date/year in the cmos setup.

Incorrect. OS clock has nothing to do with BIOS clock. It can be used as reference at boot, that's it.

[linuxforever]

Incorrect!!
If in the bios you set the time/date/year the time is set and we call it the clock.
This is independent of the OS, and will keep running, even if no OS is running.
If you start an OS this will takeover this timesettings, called the clock.
If you correct the time with the OS this will correct the bios also.
And if you should start say msdos from the old days, this OS will also takeover the time settings.
The same if you start a modern windows or linux GUI OS.
They will takeover the timesettings in the bios.
And you can correct them accordingly.
A NTP program will do this continually.