In Keith Eisenbath <> wrote:
> First ? thanks fo the reply.

> Second ? Yes that is how I thought it was to behave...

> however on a linux ntp client I get the following:

> [root@linux keith]# /usr/sbin/ntpdate
> 13 Nov 05:44:20 ntpdate[3866]: no server suitable for synchronization found

That's because Timesync is not a good source for time. For that, use
something using either ntpd or xntpd. Happily, NetWare has an xntpd.nlm
you can use for this.

> and a cisco router reports:

> router#sh ntp status
> Clock is unsynchronized, stratum 16, no reference clock
> nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**18
> reference time is 00000000.00000000 (18:00:00.000 CST Thu Dec 31 1899)
> clock offset is 0.0000 msec, root delay is 0.00 msec
> root dispersion is 0.00 msec, peer dispersion is 0.00 msec

Stratum 16 is the key thing. This is Timesync telling your NTP client that
it considers itself 'bottom' of the time stratum, and it can't be trusted
for honest time. Which is true *as far as NTP is concerned*.

> router#show clock
> *19:36:05.389 CST Sun Mar 7 1993

> So I must be doing something wrong...

Your stratum number might change if you point your Timesync server at a
Stratum 2 or Stratum 3 NTP source. But that didn't happen the last time I
checked it, which was with a NW5.1 Timesync. And in all honesty, it would
be wrong of Novell to have added that capability in the newer TimeSyncs.

Looks to me like you should be using xntpd.nlm instead of timesync.

Novell, it does a network good