Subject: Re: timed where can I connect?
To: None <netbsd-help@NetBSD.ORG>
From: William O Ferry <WOFerry+@CMU.EDU>
List: netbsd-help
Date: 07/01/1998 12:16:42
Excerpts from internet.computing.netbsd.netbsd-help: 1-Jul-98 Re: timed
where can I connect? by John Maier@mail.kemper.o 
> xntpd is very complicated and does a lot more that just check a time
> server and set the local clock.

    I've found it to be rather picky, too.  It worked fine for me for
the 3 years I ran it in my dorm, fully connected via 10base-T.  Now that
I've graduated and on a dialup I've had very little success.

    I launch xntpd via rc.conf, so it starts before I connect via PPP. 
It complains that it can't find the route to the servers, and sits
quiet.  When I dial up, it syslogs connections to the servers I
specified, and I can see the ntp packets occasionally via tcpdump, but
it *never* sets a stratum level no matter how long I leave it connected.
 This makes it rather useless as a server to the rest of my internal
network, since ntpdate won't listen to a "stratum 16" server, which is
what my dial up host reports.  I've found if I launch xntpd after
connecting via PPP, it will set the correct stratum after 15-30 minutes,
although it's clock is generally 2-3 seconds off of the servers it used
to set itself (according to ntptrace and such).  I changed my local
network to have the dialup server be a broadcast server and the other
machines just listen to the broadcasts, which has the benefit of
removing the complaint at startup (of the machines not being able to
connect to a valid time server, since the dialup is stratum 16), but
since xntpd only broadcasts if it was started after PPP this doesn't
help much...  =(

    I've been meaning to add an rdate equivalent to the rc.conf ntpdate
feature (since at least that should always work, and some of my
machine's clocks REALLY skew when they've been turned off), if anybody's
interested I'll send a PR when I get around to doing it (prolly 3-4
weeks).

    I figure my problems are much more related to UDel's xntpd than
anything NetBSD related, but I figured I'd point them out here in case
anybody has a fix or has not had this problem on their setup.  Thanks in
advance.

                                                          Will Ferry

------------------------------------------------------------------------
 William O Ferry  <woferry@CMU.EDU> | finger: woferry@Light.RES.CMU.EDU
 http://light.res.cmu.edu/~woferry/ | talk:   finger for online status
------------------------------------------------------------------------