ntp - time difference

[Roger Baptiste]

hi,

I need to configure NTP on two systems which are in cluster. So far so good.
But, these two systems have
their clocks 10 minutes ahead
from the other systems (which
have NTP running).
My question is: if i configure
NTP on these two systems and
start the ntp daemon:

-will it bring the clock on par with the NTP server gradually?

-or will it fail since it
is 10 minutes apart?

- or will the ntpdate -b in
the startup script (/sbin/init.d/xntpd) automatically set the time
to that of NTPSEVER''s time??

If it does change the time
in one shot, will it not
affect any function of the
cluster, since it is as good
as running "'date "" command and turning the clock back??

Since this is a production cluster, i don''t want to leave anything to chance.

thanks
-raj

[James R. Ferguson]

Hi:

Several comments. First, if the time difference between your source and your server is 1000 seconds or greater, then your 'xntpd' daemon will die.

Normally, 'xntp' will step the clock in one or more steps which may be fairly large. This is usually not a problem if your server's time is behind the reference source, but it still may be undesirable.

You can use 'ntpdate' during startup to adjust your time to near-correctnesss and then start 'xntpd'. Do *not* try to run both at the same time since they use the same port number.

You can adjust your time gradually with 'date [-a [-]sss [. fff]]'.

You can setup 'xntp' to slew time gradually, but note the man page discussion here:

http://docs.hp.com/hpux/onlinedocs/B2355-90692/B2355-90692.html

Regards!

...JRF...

[John Poff]

Hello RajMan,

My experience with NTP is that it figures out how far out of sync it is with the correct time and then corrects it at one shot. I've turned it on before and watched syslog, and I saw the messages recording the time differences and thought, "Oh, it's going to do it gradually." Then after a few minutes it fixes it all at once. The man page for NTP says it will correct time differences up to 1000 seconds (16 2/3 minutes) so you should be ok starting with a ten minute difference.

I've setup NTP on production machines in clusters before and I haven't had any problems. HP-UX and the MC/SG daemons seem to just get it right and not complain about it.

Have fun!

JP

[A. Clay Stephenson]

In your case when it is essential to know what is going to happen rather than guessing whether a scheme will work, I would write a small C program to use adjtime to gradually slew time back by 600 seconds and then start NTP. It is important that you run this program on both nodes in the cluster as if the nodes get too far apart in time that too can bring down a cluster.

#include
#include

#define DELTA -600L /* - 10 minutes */

int main()
{
int cc = 0;
struct timeval delta;

delta.tv_sec = (unsigned long) DELTA;
delta.tv_usec = 0;
cc = adjtime(δ,(struct timeval *) NULL);
return(cc);
}
If we wre going forward ntddate would not be a bad option but going backwards must be slewed. The change will take a while to complete (that's the idea) so be patient.

man adjtime for details on how this works.

Regards, Clay

[Bill Hassell · Accepted solution]

If you have the latest NTP patch, the man page will show:

ntpdate -B

and this will slowly slew the time until it is in sync. There will be no missed seconds so databases are happy. If you don't have ntpdate -B in your man page, get the patch, ro just reboot since the process of starting NTP services will perform a time step prior to user processes starting. I've not heard that xntpd will perform a step change (ie, more than 1 second).

[Roger Baptiste]

Thanks everybody for the responses.

Bill,

By default the xntpd startup script in /sbin/init.d has -b option. Do i need to change this to -B ?? otherwise, even after i install the new version, it will end up running with -b.
Also, do you recommend -B over -b for all times?

John,
Yeah that 1000seconds limit is within my range. But the
correcting at "one shot" seems a bit unnerving ;-) If this was a standalone or dev box, i would have given it a shot.

JRF,
I considered running date command to change the time, but since it is turning the clock back, i didnt want to try it on a running system which have user job schedules constantly running.

Clay, Thanks for the scripts.
Gives another view of the problem.

Based on all the suggestions, i will make use of a maintenance time in the next couple of weeks to install the patches, setup NTP, set the
ntpdate with -B in the startup script and reboot both the nodes.

-raj(prudent)man

[John Bolene]

I use the following program which is a bit smarter than JRF's but similar


#include
#include
#include

int call_adjtime(delta, olddelta)
struct timeval *delta;
struct timeval *olddelta;
{
int retval;

retval = adjtime(delta, olddelta);
if(retval != 0) {
perror("adjtime");
}
return(retval);
}

main(argc, argv)
int argc;
char **argv;
{
char *prog;
struct timeval delta, olddelta;
int retval;

if((prog = (char *)rindex(*argv, '/')) == NULL) {
prog = *argv;
}
else {
prog++;
}

if(argc != 2) {
fprintf(stderr, "Usage: %s seconds\n", prog);
exit(1);
}

delta.tv_sec = atoi(argv[1]);
delta.tv_usec = 0;
olddelta.tv_sec = 0;
olddelta.tv_usec = 0;

retval = 1;
while(retval != 0) {
retval = call_adjtime(δ, &olddelta);
}
for(;;) {
delta.tv_sec = olddelta.tv_sec;
delta.tv_usec = olddelta.tv_usec;
call_adjtime(NULL, &olddelta);
if(olddelta.tv_sec == 0 && olddelta.tv_usec == 0) {
if(delta.tv_sec == 0 && labs(delta.tv_usec) < 100000) {
break;
}
else {
call_adjtime(δ, &olddelta);
call_adjtime(NULL, &olddelta);
}
}
printf("remained %d.%06d\n", olddelta.tv_sec, labs(olddelta.tv_usec));
sleep(1);
}
}