On Tue, 25 Jul 2006 16:57:27 +0200,
Jan Ceuleers <[EMAIL PROTECTED]> wrote:
> Note that the IP address of the current sys_peer is 213.222.11.222
> (which is what gets output in binary as the refid).
>
> One more data point: here is the output of 'ntpq -p -c rv localhost'
> which ntptrace turned into the above output:
>
> assID=0 status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
> version="ntpd [EMAIL PROTECTED] Sun Jul 9 11:18:35 UTC 2006 (1)",
> processor="i686", system="Linux/2.4.20-28.7", leap=00, stratum=1,
> precision=-20, rootdelay=0.000, rootdispersion=451.539, peer=63864,
> refid=ÕÞ
> Þ, reftime=c870ad28.383ed848 Tue, Jul 25 2006 16:46:00.219,
> poll=10, clock=c870ae8d.6d58d599 Tue, Jul 25 2006 16:51:57.427,
> state=4, offset=0.497, frequency=6.306, jitter=3.058, noise=2.836,
> stability=0.003, tai=0
>
> So: this problem is not caused by ntptrace; the incorrect refid, stratum
> etc. are already shown by the ntpq -n -c rv output.
It's not a problem with ntpq either, looking at that. If ntpd is
reporting itself as stratum-1, the refid should be the text tag of
its refclock. If ntpd has switched sys_peer from the refclock to
a server, it shouldn't be reporting itself as stratum-1 ...
--
Ronan Flood <[EMAIL PROTECTED]>
working for but not speaking for
Network Services, University of London Computer Centre
(which means: don't bother ULCC if I've said something you don't like)
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
