xntpd Time Slewing Confusion

[Lee Harris_5]

After reading some other threads and the odd man page I decided to have a go at changing the time on one of our servers but also to use slewing.

I added the NTP server to the bottom of /etc/ntpd.conf, then editted /etc/rc.config.d/netdaemons changing the variables:

NTPDATE_SERVER=time.mycompany.com
XNTPD=1
XNTPD_ARGS=-x

I then ran /sbin/init.d/xntpd start

And it seemed that instantly the time had gone back by 5 minutes! I kind of expected it to gradually drift but this did not appear to be the case and I can't understand why. I don't think I've trashed the application or Sybase database...but time will tell :-S

[Ivan Ferreira]

This is normal, when you start the service, it runs:

/usr/sbin/ntpdate -b ${NTPDATE_SERVER}


This will set the system time exactly as the NTP SERVER time, then will keep synchorized. This is required to start the synchronization.

[Lee Harris_5]

Well doesn't that kind of make the XNTPD_ARGS=-x bit pointless? I mean the idea is that the -x says make all changes by slew, but if it does that first off then it kind of defeats the object.

So how would I go about have the effect I was originally expecting?

[Jeff Schussele · Accepted solution]

Hi Lee,

You should have used the following:

date -a -300

to slew the time back 300 seconds (5 minutes)
NTP did what it normally does - adjust immediately when started because, at boot, there is no SW running yet.
Next time get the time back to just a short time behind actual time before starting xntpd.
Going fwd never causes trouble.

HTH,
Jeff

[rick jones]

Just a guess, but had you not filled-in the NTPDATE_SERVER line it might not have run ntpdate and so the time would not have been stepped.

It is goodness to run ntpdate when the system first boots, but if you are starting the xntpd in the middle of the system being up, you might want to simply start xntpd by hand as in:

xntpd -x

and of course check syslog to make sure that xntpd will indeed sync with the time source. IIRC if the time is too far out of wack, xntpd will not sync and will request that someone bring the time back into closer sync manually - often as not by running something like ntpdate :)

[rick jones]

Just a guess, but had you not filled-in the NTPDATE_SERVER line it might not have run ntpdate and so the time would not have been stepped.

It is goodness to run ntpdate when the system first boots, but if you are starting the xntpd in the middle of the system being up, you might want to simply start xntpd by hand as in:

xntpd -x

and of course check syslog to make sure that xntpd will indeed sync with the time source. IIRC if the time is too far out of wack, xntpd will not sync and will request that someone bring the time back into closer sync manually - often as not by running something like ntpdate :)

BTW, I hope you have more than one NTP server configured into your ntp.conf file. Just as one should configure multiple DNS servers into /etc/resolv.conf, one should configure multiple time servers into /etc/ntp.conf.

[Bill Hassell]

Rick explained the process. When you run the xntpd script in /sbin/init.d, the first thing that is done is a step change, which is correct for bootup. If you wnated to simply change the xntpd option to -x, then you should manually kill xntpd and start it again with the -x option.

Now it's important to understand that xntpd will keep the time in sync without using -x. NTP is a very complex protocol that works best with several stable NTP servers and adjusts time only a fraction of a second at a time. NTP insures that exactly 86400 seconds will occur during each day. If your local machine runs fast or slow, very small adjustments are made to keep within the 128ms window NTP uses.

Whenever there is a big difference between the local time and the server, it is best to use ntpdate -B (not -b) command to sync the time between your local system and the NTP server. Note that a 10 minute difference will take several hours to complete. During that time, you don't run xntpd. If the time difference a lot more than 10 minutes, ntpdate will not be able to slew the time. In that case, you shutdown all applications and use ntpdate -b to step or jump the time. Using ntpdate -B rather than date -a means that accidental mistakes due to TZ values will not affect the true time. NTP keeps the system time as GMT regardless of what timezone is selected.

As a general note, databases such as Sybase, Oracle, Informix, etc are very susceptible to data integrity problems when time jumps backwards. It depends on how important the local time has been made in the database design. It means that the database will see the same time more than once, something that is unexpected.