Very Computer

Everybody talks about how we need a FAQ, but nobody does anything about it.
So I decided to do something about it.  Here is the text of several recent
messages that answered questions that everyone agrees should be on a FAQ.

Send updates to me --
Please write it up in a form I can include in the FAQ, and I'll include it.

Note, This is a "non-fat" FAQ.  I include stuff from other people that
I think is applicable.  I include it as it comes to me, warts and all.
I don't usually write things myself because I don't have the time.  I
don't usually edit things unless I write them myself.

Because of the un-edited format, you should read the *whole thing*
before you act on anything you read here.  Frequently, later items
contain corrections to earlier items.  I have tried to group related
items together, but sometimes that is not possible.

I post the accumulation once a month.

It's rough but ready.

========================================================================
Rick Thomas, Manager Supercomputer Remote Access Center
Rutgers University, College of Engineering
Internet: rbtho...@jove.rutgers.edu
UUCP: {any backbone site}!rutgers!rbthomas
========================================================================

Standard disclaimers apply.  All messages quoted here are the opinions
of their respective authors, and do not necessarily represent the opinions
(if any) of their respective employers, or of the compiler of this FAQ.

=============================================================================
From: igles...@draco.acs.uci.edu (Mike Iglesias)
Subject: Re: xntpd: previous time adjustment didn't complete

Make sure you run tickadj on your Suns before you run xntpd.  Here's
how we run tickadj:

   tickadj -A -s -q -t 9999

You can leave off the -t 9999 if you want.  We find that our Suns drift
less with that setting.

Also, if you don't use a window system on the console, the slow console
proms will make the system loose interrupts and the time will drift.

We *really* need a FAQ for this list.  This question gets asked several times
a month.  :-(

=============================================================================
From: gl...@athena.cs.uga.edu (Glenn F. Leavell)
Subject: Re: xntpd: previous time adjustment didn't complete

I recently worte:

Thanks very much to everyone who responded to my question (both via e-mail
and directly to the net.)  The consensus seems to be that the Sun clock
is a very bad one.  I was already using 'tickadj -A' to set the value
of tickadj to an optimal value in the running kernel.  However, a couple
of other paramaters are also useful (and most likely necessary):

                tickadj -A -s -t 9999

The -s option sets the value of dosynctodr to zero in the running kernel.
This has the effect of telling the OS to stop trying correct the clock's
drift (the work is left for xntp!).  The -t 9999 option sets the value
of tick in the running kernel to 9999.  According to several of the responses
I received, this is a good value for most Suns.  However, I have not seen
a complete list.

Thanks again for the help.

=============================================================================
From: igles...@draco.acs.uci.edu (Mike Iglesias)
Subject: Re: ntpdate: errors when trying to synch to other xntp hosts
Keywords: ntpdate xntp3

Make sure those systems can convert hostnames to IP addresses at that point
(i.e. make sure everything necessary to use nameservers is up and running
if you are using them), and that any routing that needs to be setup is in
place before you run ntpdate.  

Maybe those hosts can get to the servers that work but not the other ones,
as I mentioned above.

YES!  PLEASE!

=============================================================================
From: Mi...@UDEL.EDU
Subject: Re:  NTP peers

chongo,

I do not have the resources to provide individual configuration advice
for a specific installation - there are many thousands of them now. The
ntpd (version 1) distribution has been obsoleted twice over and been
replaced by NTP Version 3. A comprehensive Unix daemon is available
in the compressed tar archive pub/ntp/xntp3.tar.Z on louie.udel.edu.
It includes scads of information on installation, configuration and
peer selection. Other files in the pub/ntp/doc directory on that host
contain probably more than you will ever care to know about timekeeping
in general and, in particular, the file clock.txt, which contains a
list of public stratum-1 and stratum-2 time servers. Happy chime.

Dave

=============================================================================
From: jo...@hermes.chpc.utexas.edu (William L. Jones)
Subject: Just a few small suggestions!

Thanks!

We really need a faq for comp.protocols.time.ntp.

When you talk about using tickad on a sun you need to mention that
if you are running Sun OS 4.1.3 you don't need the "-t 9999" on tickadj.

Bill Jones

=============================================================================
From: gee...@ica.philips.nl (Geert Jan de Groot)
Subject: Re: Reachability keeps resetting zero after a STEP

I have the same problem, but after a note from Dave it now seems to be
solved. Dave, please correct me if I am wrong, and maybe it is a good idea
to include it in the notes files..

The first problem is that SUNs have too much tolerance on their clocks.
Because NTP requires removal of synchonisation to the built-in
NVram clock (that is where tickadj -s option is for, to reset dosynctodr).
Now your SUN really starts drifting, and ntp tries to get up with
that, but because the clock error is high (several hundreds of ppm),
NTP does not succeed at first, and it takes a few days to adjust.
In that time, the SUN will frequently loose synchonisation , which
you can determine by looking at the status words in your log file,
combined with appendix A of RFC1305.
Hence, it is a bad idea to have the SUN synchonize anything else.
Wait for things to stabilize first!

The approach I used is to start xntpd on a new machine (as slave - I didn't
want to confuse the server I used), wait for two or three days, and then
check /etc/ntp.drift. Because xntpd raises or lowers the drift value only a
few ticks per hour, at first xntp is not able to correct the frequency
error. After a while, the time error between your clock and the reference
gets higher and higher and xntpd starts to complain:

Then, after a while, some hold-off timer times out and the time is
SET, no longer ADJUSTED. This is what you see:
As a result, xntpd declares itself invalid and starts to synchonize:
After a while, xntpd synchonizes again and declares healthy again:
and the thing starts over again. In time, these events happen less and
less often, until the drift value is close enough that xntpd is able
to steer the local time within its limits.

The basic idea is to sit on your hands for a few days, don't use the
server (yet) to ...

read more »

Everybody talks about how we need a FAQ, but nobody does anything about it.
So I decided to do something about it.  Here is the text of several recent
messages that answered questions that everyone agrees should be on a FAQ.

Send updates to me --
Please write it up in a form I can include in the FAQ, and I'll include it.

Note, This is a "non-fat" FAQ.  I include stuff from other people that
I think is applicable.  I include it as it comes to me, warts and all.
I don't usually write things myself because I don't have the time.  I
don't usually edit things unless I write them myself.

Because of the un-edited format, you should read the *whole thing*
before you act on anything you read here.  Frequently, later items
contain corrections to earlier items.  I have tried to group related
items together, but sometimes that is not possible.

I post the accumulation once a month.

It's rough but ready.

========================================================================
Rick Thomas, Manager Supercomputer Remote Access Center
Rutgers University, College of Engineering
Internet: rbtho...@jove.rutgers.edu
UUCP: {any backbone site}!rutgers!rbthomas
========================================================================

Standard disclaimers apply.  All messages quoted here are the opinions
of their respective authors, and do not necessarily represent the opinions
(if any) of their respective employers, or of the compiler of this FAQ.

=============================================================================
From: igles...@draco.acs.uci.edu (Mike Iglesias)
Subject: Re: xntpd: previous time adjustment didn't complete

Make sure you run tickadj on your Suns before you run xntpd.  Here's
how we run tickadj:

   tickadj -A -s -q -t 9999

You can leave off the -t 9999 if you want.  We find that our Suns drift
less with that setting.

Also, if you don't use a window system on the console, the slow console
proms will make the system loose interrupts and the time will drift.

We *really* need a FAQ for this list.  This question gets asked several times
a month.  :-(

=============================================================================
From: gl...@athena.cs.uga.edu (Glenn F. Leavell)
Subject: Re: xntpd: previous time adjustment didn't complete

I recently worte:

Thanks very much to everyone who responded to my question (both via e-mail
and directly to the net.)  The consensus seems to be that the Sun clock
is a very bad one.  I was already using 'tickadj -A' to set the value
of tickadj to an optimal value in the running kernel.  However, a couple
of other paramaters are also useful (and most likely necessary):

                tickadj -A -s -t 9999

The -s option sets the value of dosynctodr to zero in the running kernel.
This has the effect of telling the OS to stop trying correct the clock's
drift (the work is left for xntp!).  The -t 9999 option sets the value
of tick in the running kernel to 9999.  According to several of the responses
I received, this is a good value for most Suns.  However, I have not seen
a complete list.

Thanks again for the help.

=============================================================================
From: igles...@draco.acs.uci.edu (Mike Iglesias)
Subject: Re: ntpdate: errors when trying to synch to other xntp hosts
Keywords: ntpdate xntp3

Make sure those systems can convert hostnames to IP addresses at that point
(i.e. make sure everything necessary to use nameservers is up and running
if you are using them), and that any routing that needs to be setup is in
place before you run ntpdate.  

Maybe those hosts can get to the servers that work but not the other ones,
as I mentioned above.

YES!  PLEASE!

=============================================================================
From: Mi...@UDEL.EDU
Subject: Re:  NTP peers

chongo,

I do not have the resources to provide individual configuration advice
for a specific installation - there are many thousands of them now. The
ntpd (version 1) distribution has been obsoleted twice over and been
replaced by NTP Version 3. A comprehensive Unix daemon is available
in the compressed tar archive pub/ntp/xntp3.tar.Z on louie.udel.edu.
It includes scads of information on installation, configuration and
peer selection. Other files in the pub/ntp/doc directory on that host
contain probably more than you will ever care to know about timekeeping
in general and, in particular, the file clock.txt, which contains a
list of public stratum-1 and stratum-2 time servers. Happy chime.

Dave

=============================================================================
From: jo...@hermes.chpc.utexas.edu (William L. Jones)
Subject: Just a few small suggestions!

Thanks!

We really need a faq for comp.protocols.time.ntp.

When you talk about using tickad on a sun you need to mention that
if you are running Sun OS 4.1.3 you don't need the "-t 9999" on tickadj.

Bill Jones

=============================================================================
From: gee...@ica.philips.nl (Geert Jan de Groot)
Subject: Re: Reachability keeps resetting zero after a STEP

I have the same problem, but after a note from Dave it now seems to be
solved. Dave, please correct me if I am wrong, and maybe it is a good idea
to include it in the notes files..

The first problem is that SUNs have too much tolerance on their clocks.
Because NTP requires removal of synchonisation to the built-in
NVram clock (that is where tickadj -s option is for, to reset dosynctodr).
Now your SUN really starts drifting, and ntp tries to get up with
that, but because the clock error is high (several hundreds of ppm),
NTP does not succeed at first, and it takes a few days to adjust.
In that time, the SUN will frequently loose synchonisation , which
you can determine by looking at the status words in your log file,
combined with appendix A of RFC1305.
Hence, it is a bad idea to have the SUN synchonize anything else.
Wait for things to stabilize first!

The approach I used is to start xntpd on a new machine (as slave - I didn't
want to confuse the server I used), wait for two or three days, and then
check /etc/ntp.drift. Because xntpd raises or lowers the drift value only a
few ticks per hour, at first xntp is not able to correct the frequency
error. After a while, the time error between your clock and the reference
gets higher and higher and xntpd starts to complain:

Then, after a while, some hold-off timer times out and the time is
SET, no longer ADJUSTED. This is what you see:
As a result, xntpd declares itself invalid and starts to synchonize:
After a while, xntpd synchonizes again and declares healthy again:
and the thing starts over again. In time, these events happen less and
less often, until the drift value is close enough that xntpd is able
to steer the local time within its limits.

The basic idea is to sit on your hands for a few days, don't use the
server (yet) to synchonize ...

read more »