SUMMARY: xntpd behavior with network failure

Setting the date in the OS does indeed reset the date in BIOS.

Time Spent Grammar Checking vs. Time Spent Testing & Fact Checking
will be better considered .

Thanks!

etc:
You may want to go to the official xntp source:

http://www.eecis.udel.edu/~ntp/

Thanks to Darren Dunham who answered my other questions: (Embedded in the
original Q)

----- Original Message -----
From: "Brett Thorson" <bthorson@ekosystems.com>
To: <sunmanagers@sunmanagers.org>
Sent: Tuesday, August 21, 2001 1:46 PM
Subject: Q: xntpd behavior with network failure


> The brief question is this:
> Can xntpd be relied upon in the case of network failure accompanied with a
> reboot?
>
> The scenario:
> Solaris 8 x86 (Note: All Intel Hardware)
> BIOS Date of 7/12/1995 (For example)
>
> The network is up:
> Machine boots. xntpd starts up, it hits the server listed in the
xntpd.conf
> file (The preferred server) and the time is updated.
> Well, the time is updated as long as the OS is up, and the box isn't
> rebooted.  My understanding is that there is no way that I can change the
> date in BIOS from the OS.  Which means that everytime the machine boots, I
> am reset to the BIOS date, and then I must correct myself.
>
> What happens when the network is down?
> xntpd starts up, no network is found.
> Date remains at 7/12/1995 until the network connection is restored.
>
> 1) Does xntpd get notified of the restored network connection and
> immediately update?
>

xntpd will continue to poll.  Assuming the network comes up, its polls
will be answered.  Unfortunately, if the current time and the poll time
differ by more than 1000 seconds, then xntpd will assume something is
horribly wrong, and will exit and log a message in syslog.


> Now I see mention of a drift file.  I was hoping that was going to be my
> saving grace, but I don't quite understand its complete function in all
> this.  It looks as if it has something to do with the frequency of the
clock
> it is syncing from.
>
> 2) Other than properly setting BIOS, and putting an Atomic Clock receiver
on
> each machine, are there any other options to ensure that the system has
the
> proper time setting on bootup?
>

Sort of.  It's really the error in the local clock frequency.  If xntpd
starts without sync (say after a reboot), then it will read the drift
file and discipline the clock to that frequency.  That's quite useful if
the bios clock is "close".  If the bios is getting reset back to 1995,
then it's of no use at all.


> Thought: Grab the # of seconds for the Bios clock.  Grab the # of seconds
of
> a confirmed good clock.  Calculate the difference.  Always apply this
> difference to the clock whenever we boot?

No..  If the bios clock is moving forward, then it should be set.

>
> Thanks much!
>
> --Brett
>