Showing results for 
Search instead for 
Do you mean 

NTP stepping forward too fast

Honored Contributor

NTP stepping forward too fast

Hi all, I have a little problem. (Excuse my english also)

Trucluster 5.1B PK5 4 nodes. NTP with default configuration, all nodes are setup as peer. No external clock reference (We cannot use them because we do the time change out of the official days). The TIMEZONE is GMT-4.

Last week we changed the time of our servers to match the summertime time. We did not changed the TIMEZONE.

Before the change, we saw that the time was 20 minutes forward. Then we set the new time (forwarded 1 hour), and the system clock was as it should be for the new time.

But, now after a week, we see that the system time of the nodes are 8 minutes forward again.

Why the system clock of the nodes are going forward and forward?

This is a sample configuration of one of the nodes (All are more or less the same)

driftfile /cluster/members/{memb}/etc/ntp.drift
server 127.127.1.0 version 3
fudge 127.127.1.0 stratum 12
peer esb-ics0 version 3
peer gsa-ics0 version 3
peer gsb-ics0 version 3


Please advice.
Por que hacerlo dificil si es posible hacerlo facil? - Why do it the hard way, when you can do it the easy way?
15 REPLIES
Honored Contributor

Re: NTP stepping forward too fast

Hi,

since you defined three peers for the definition of the system time, some form of average is calculated from them. So, if one of them is gaining, they all will.

greetings,

Michael
Honored Contributor

Re: NTP stepping forward too fast


Ivan,

The 3 members should NOT have the SAME stratum, so change the ntp.conf of 2 members giving 1 member a stratum of 10 and another a stratum of 8.
Make sure that XNTP_SERV1 and XNTP_SERV2 in /etc/rc.config on each member points to the other 2 members.

After that, run "/sbin/init.d/xntpd stop" on all members, delete the ntp.drift file on all members and restart ntp on each member as follows:

On one member:
Manually set the time
/sbin/init.d/xntpd start

Wait until "ntpq -p" shows that this member is synchronized

On the other members:
/sbin/init.d/settime start
/sbin/init.d/xntpd start

Have fun,

__ Johan /.

_JB_
Esteemed Contributor

Re: NTP stepping forward too fast

Note that NTP is responsible for syncronizing time, but it has nothing to do with how time is presented to you (i.e. the timezone). So I believe you should be able to use a few external time sources too.

You could change the time zone definitions in /etc/zoneinfo/sources and add your own personal time zone if you like. That way you don't have to manually change the time on a running system and confuse your applications.

Honored Contributor

Re: NTP stepping forward too fast

Thanks to all, I agree with all responses:

If one member steps forward, all will do.

I will try changing the stratum of the servers, leaving one of these servers with high stratum.

I cannot use an external source because in our country (and the only I think) we don't change the time in the day that should be. Is dictated by the goverment.

If the problem is solved changing the stratum, I will let you know, and please post anything so I can give you the points that you deserve.

Thanks to all, and any new contributions are welcomed.
Por que hacerlo dificil si es posible hacerlo facil? - Why do it the hard way, when you can do it the easy way?
Esteemed Contributor

Re: NTP stepping forward too fast

Ivan,

I don't believe this needs to be a problem. Normally the time is kept in UTC in the kernel. This is the time that is adjusted by NTP and it doesn't change when switching between daylight savings time or even when changing timezones.

The time that is displayed is based on the timezone. The timezones for your area are in /etc/zoneinfo/sources/southamerica. It includes the timezone for Paraguay. But when you take a look at it, you can see that the rule can change every year. This file may not always have the latest decisions from your government, but you could decide to change it and recompile it. It might keep you in bed during the time changes! :-)
Respected Contributor

Re: NTP stepping forward too fast

Ivan,

It is 100% correct that ntp only works with the UTC, and UTC time is not influenced by Daylight Settings. This time is the same around the globe. So, I don't see why you can not use an external timesource.

One thing that you should check, is the drift value in the ntp.drift file.
If you have a high drift value, which does not reflect the real drift of your hardware, then you will see that time is lost or gained.

To solve this,
- stop the ntp daemons
- remove the drift file
- restart the ntp daemons.

After a couple of hours, the driftfiles will be filled with driftvalues that are more likely. Normally, the drift stays within an interval [ -15, 15 ]


Happy syncing
To err is human, but to really faul things up requires a computer
Honored Contributor

Re: NTP stepping forward too fast

The problem isn't solvet yet. Now, the extrange thing is that even the servers that do not use ntp, are stepping forward.

This happened after a time change to match daylight saving time. We do not use a TIMEZONE to handle the daylight saving time. I think that I will need to compile one.

If the server does not use ntp, can the time be adjusted based on the TIMEZONE?
Por que hacerlo dificil si es posible hacerlo facil? - Why do it the hard way, when you can do it the easy way?
Honored Contributor

Re: NTP stepping forward too fast

I don't think it's at all strange that servers that aren't using NTP are drifting forward - your configuration is relying solely on the internal clocks of these servers and there's no way to make them accurate. You need to get UTC from an external source. As previous posts have pointed out your TIMEZONE setting - as dictated by your local government - has nothing to do with UTC. Once you get NTP running on these servers and sync'd up with an accurate UTC source, you can use TIMEZONE to get your clock set to the correct local time.
Honored Contributor

Re: NTP stepping forward too fast

Thanks to all for the responses. I think that you all are right. Is just too extrange for me (maybe not for you) that all servers drift forward (so fast). I tried with a good timezone for my country, compiled by hand (without NTP) still is stepping forward.

Also, other people that uses the same hardware and software configuration does not have the problem, maybe their clocks are more accurate.

I think that the solution will be to use an external time source.

As before, if that is the solution that will be implemented, another post will be required to close the thread and assign the corresponding points.

Thanks!
Por que hacerlo dificil si es posible hacerlo facil? - Why do it the hard way, when you can do it the easy way?
Esteemed Contributor

Re: NTP stepping forward too fast

Ivan,

As said before, the timezone has nothing to do with keeping an accurate time.

The TOY clock used in the hardware is not highly accurate. Basically they use the same technology that normal (digital) watches use. I couldn't find the accuracy for the AlphaServer systems, but I did look up the one for VAX (since I knew where that reference was). The worst accuracy there is 0.0025% (or about 65 seconds per month). I'm sure the AlphaServer systems are not worse.

So if you say that you have systems that gain 8 minutes in a week AND you're NOT using NTP on those systems, then I would think it is worth opening a call for this. Could be hardware, software or a combination.
Esteemed Contributor

Re: NTP stepping forward too fast

Well... actually, the TOY clock is used to keep system time when the system isn't running. To keep track of time on a running system, an interval timer is used. But still 8 minutes a week seems too much.
Honored Contributor

Re: NTP stepping forward too fast

Thanks Han, we will open a call to HP because we think that the time inaccuracy is too high.

I will keep you informed.
Por que hacerlo dificil si es posible hacerlo facil? - Why do it the hard way, when you can do it the easy way?
Respected Contributor

Re: NTP stepping forward too fast

Ivan,

As you mentioned before. The best solution is to go for an external timesource with a good compiled timezone.

Some remarks:

It would surprise me, if this is a HW problem.
I want to believe that 1 system gains in time.
But the chance that ALL your systems gain in time (due to HW) is practically zero.

The system time, once the OS is running, is kept up to date by the OS itself (i.e. the software), not by the hardware.Correct me if I'm wrong. Maybe, some kernel variable, that modifies clock_interrupts, has been changed.

Also, I suppose that your systems don't carry a very high load. Most of the time, systems will trail in time, because clock_interrupts are lost due to high interrupt loads.

Anyway, You should contact HP for support.

To err is human, but to really faul things up requires a computer
Honored Contributor

Re: NTP stepping forward too fast

Thanks again, we are currently testing the system with external NTP servers and custimized zone file. I don't know if I will open a call, bynow, this is solving the problem.

As you said, I don't think also that is a hardware problem (in all), but something weird with the OS and the firmware or something like that. I'm just curious that if we don't use an external NTP source, how can the system time maintained accurate if all servers are having the same problem?

I will keep you informed. Right now, I really don't know what really happened because all configuration changes that I have done. I need to start again to verify that servers that don't use ntp really are stepping forward. And that is why I won't open a call yet.
Por que hacerlo dificil si es posible hacerlo facil? - Why do it the hard way, when you can do it the easy way?
Honored Contributor

Re: NTP stepping forward too fast


One thing that was not mentionned before in this thread, still to check.

Do you have the following line in the kernel config file /usr/sys/conf/HOSTNAME ?!

options NTP_TIME



Rgds,
Johan.

_JB_
//Add this to "OnDomLoad" event