On Wed, Jan 05, 2000 at 02:00:44PM -0800, Rick Johnson wrote:
>
>
> > Yo, Sean-Paul, your clock be needin adjustment. On linux, this works,
> >
> > $ su
> >
> > # netdate cuckoo.nevada.edu
>
> Not on Redhat.
>
> > anyone else got another way for syncing your clock?
>
> I use "ntpdate" which is part of the xntpd package. Can you give us more
> info on netdate?
Here is the man page. I use debian, and I don't know where you get
netdate from, but I would bet it is GNU. I don't have ntpdate on my
system. I apologize for the repeat letters which were inserted when I
executed the command and had its output inserted into the email.
$ man netdate
NETDATE(8L) NETDATE(8L)
NNAAMMEE
netdate - set date and time by ARPA Internet RFC 868
SSYYNNOOPPSSIISS
netdate [ -v ] [ -l limit ] [ protocol ] hostname...
DDEESSCCRRIIPPTTIIOONN
Netdate takes a list of names of Internet hosts as argu
ments, selects the one which supplies the best time, and
sets the system time accordingly. The invoker must be the
super-user for the time to be set. Protocol names (either
uuddpp or ttccpp) may be interspersed with the host names, and
determine the protocol which will be used to connect to
the hosts whose names follow, up to the next protocol name
or the end of the arguments. The default protocol is uuddpp.
The ``best'' time is chosen by polling the named hosts
once each to find their times and taking their differences
from the local host's time. These differences are used to
find the largest group of hosts whose times agree with
each other within a certain limit. The first host in the
largest group is picked as the best host. (The assumption
is that the hosts which are usually most accurate will be
named first.) That host is polled again and the local
host's time is set to the result. The chosen host's time
is checked on this second poll to insure that its differ
ence from the local host's time has not varied more than
the limit from its difference at the first poll.
The default limit is five seconds. It may be set with the
--ll option. The --vv option causes the groups to be shown.
The host name llooccaallhhoosstt is recognized as a synonym for the
name of the local host, no network connection is made for
it, and its time difference is always zero. If llooccaallhhoosstt
is chosen as having the best time, the system time will
not be set. Hosts which do not respond are not counted in
the groups. If the limit is set to zero, the time is set
to that of the first host to respond and no other checking
is done. Supplying only one host name argument also sets
the limit to zero.
While the RFC868 protocol only returns 32 bits of data,
containing the time in seconds, _n_e_t_d_a_t_e will accept an
extra 32 bits, containing microseconds (expected to be
accurate to no more than milliseconds). Delays on long
haul networks may make this extra precision useless, but
it is useful on local area networks. The extra precision
is not used on the first poll of a host, but it is used on
the second poll of the chosen host, if that host supplies
it.
EEXXAAMMPPLLEE
The most accurate hosts are named first in each example.
Some such call on _n_e_t_d_a_t_e should be put at the end of
85/08/21 1
NETDATE(8L) NETDATE(8L)
//eettcc//rrcc..dd//rrcc..llooccaall, so that the time will be set properly
on system startup. It is also useful to have a shell
script, e.g., //ssbbiinn//ttiimmeehhoossttss, which contains a call on
_n_e_t_d_a_t_e with arguments appropriate to the local system, so
that it is easy to set the time manually.
nneettddaattee --ll 3300 uuddpp ddccnn--ggaattee ttccpp nneeiigghhbboorr
_D_c_n_-_g_a_t_e is a hypothetical host which usually keeps time
accurate to within milliseconds of Coordinated Universal
Time, but may occasionally be eight hours off. _N_e_i_g_h_b_o_r
is a neighbor of the local host which keeps time with mod
erate accuracy. The time will be set to that of _d_c_n_-_g_a_t_e
if that and _n_e_i_g_h_b_o_r agree to within thirty seconds, else
it will not be set at all. This is almost good enough for
most circumstances, but won't do when the local host's
time is known to be wrong (e.g., after a long downtime or
a bad crash) and must be set to something. If one of the
hosts named is inaccurate or not responding, there is a
problem.
nneettddaattee --ll 3300 uuddpp ddccnn--ggaattee ttccpp nneeiigghhbboorr nneeiigghhbboorr22
Only two of the three hosts named must agree on the time.
The time will still be set (to that of the first neigh
bor), even if _d_c_n_-_g_a_t_e is far off as long as the two
neighbors agree. This is probably good enough for most
cases. One can arbitrarily gerrymander the vote for more
insurance (and less clarity), as in the following example.
nneettddaattee uuddpp ddccnn--ggaattee ddccnn11 ttccpp bbbbnn--uunniixx llooccaallhhoosstt nneeiigghhbboorr
Here _d_c_n_1 and _b_b_n_-_u_n_i_x are more hypothetical very accurate
timekeepers, at least one of which keeps time indepen
dently from _d_c_n_-_g_a_t_e, one hopes. It is very likely that
the time will be set to that one of those three very accu
rate hosts, as long as at least two of them agree, or at
least one of them agrees with the neighbor or the local
host's time. If all the foreign hosts disagree, the time
will not be set, since llooccaallhhoosstt will be chosen as best.
nneettddaattee --ll 33 llooccaallhhoosstt llooccaallhhoosstt uuddpp ddccnn--ggaattee ddccnn11 ttccpp bbbbnn--uunniixx
This example gives llooccaallhhoosstt two votes and declares it to
usually have the most accurate time. All three foreign
hosts must agree within three seconds and also differ from
llooccaallhhoossttss by more than three seconds for the time to be
set. Thus the time will be set only if it really needs to
be.
FFIILLEESS
/etc/services for the time service port number
/etc/protocols for the protocol numbers
/var/log/wtmp to record time-setting
SSEEEE AALLSSOO
ARPANET Request for Comments 868, gettimeofday(2),
date(1), WWV (USA): 2.5,5,10,15 MHz AM for Coordinated
85/08/21 2
NETDATE(8L) NETDATE(8L)
Universal Time (UCT).
DDIIAAGGNNOOSSTTIICCSS
85/08/21 3
-- Brian Lavender http://www.brie.com/brian/ **************************************************************************** * To UNSUBSCRIBE from the list, send a message with "unsubscribe lug-nuts" * in the message body to majordomo@saclug.org. Please direct other * questions, comments, or problems to lug-nuts-owner@saclug.org.
This archive was generated by hypermail 2b29 : Fri Feb 25 2000 - 14:29:09 PST