On Tue, 25 Jul 2006 16:57:27 +0200,
Jan Ceuleers 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 4.2.2p1@1.1570-o 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
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)

Harlan,

Harlan Stenn wrote:
> There is no maintainer for ntptrace, so bugs get fixed there when somebody
> feels like working on it.

This is worring: you do not seem to have caught on to the fact that this
issue is caused by ntpq -n -c rv being inconsistent with ntpq -p.

Let me say that again: ntpq is inconsistent with ntpq.

The ntptrace issue is just a symptom.

I suspect that this is another form of the problem mentioned in the
subject of this thread.

> The "default" maintainer is me, and I have over 100 bugs in my queue.
> I work on the bugs that are blocking the "upcoming" release when I am not
> working on release issues. And I'm still a volunteer and do this work in my
> spare time.

Thank you (x1000). Really!

But this is also worrying: from what you say the ntpd project is in a
constant state of fire-fighting. Releases are driven by a lack of
blocking issues, rather than by a vision of what new or improved
functionality is needed that outweighs the risks of deployment.

I would call upon the ICT industry to lend a hand, since time
synchronisation is, frankly, too important to the industry to be left to
volunteers who are very understandably forced to compromise.

My employer is a bit busy merging right now, or I'd try and get some
support going. Has anyone tried talking to industry federations?

Cheers, Jan

I was responding to an item in that thread that discussed ntptrace.

At least, I thought so...

As for the ntodc sysinfo v. ntpq -p issue, I thought I carefully described
my observation of one of the detailed reports earlier - in that case ntpq
was reporting it was sync'd to the remote server but it was still in state
3, and the sysinfo command showed that the local machine was not yet sync'd.

H

On 28 Jul 2006 13:22:17 GMT, I wrote:

> Jan Ceuleers wrote:
>
> > 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 ...

I can confirm this problem with ntpd-4.2.2, as I'm seeing this on one of
our GPS receivers which is having intermittent reception at the moment.
Here are ntpq -np outputs I happen to have logged from one of its peers
at consecutive two-minute intervals this morning:

remote refid st t when poll reach delay offset jitter

+193.62.22.74 .GPS. 1 u 20 64 377 5.780 0.087 0.055

-193.62.22.74 .>^Vb. 1 u 12 64 377 5.780 0.087 0.043

+193.62.22.74 .>^Vb. 1 u 2 64 377 5.834 0.049 0.031

-193.62.22.74 192.36.134.17 2 u 57 64 376 5.834 0.049 0.044

(>^Vb is textified ASCII of 193.62.22.98, another peer)

Time to log a bug?

--
Ronan Flood
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)

Ronan Flood wrote:
> On 28 Jul 2006 13:22:17 GMT, I wrote:
>
>> Jan Ceuleers wrote:
>>
>>> 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 ...
>
> I can confirm this problem with ntpd-4.2.2, as I'm seeing this on one of
> our GPS receivers which is having intermittent reception at the moment.
> Here are ntpq -np outputs I happen to have logged from one of its peers
> at consecutive two-minute intervals this morning:
>
> remote refid st t when poll reach delay offset jitter
>
> +193.62.22.74 .GPS. 1 u 20 64 377 5.780 0.087 0.055
>
> -193.62.22.74 .>^Vb. 1 u 12 64 377 5.780 0.087 0.043
>
> +193.62.22.74 .>^Vb. 1 u 2 64 377 5.834 0.049 0.031
>
> -193.62.22.74 192.36.134.17 2 u 57 64 376 5.834 0.049 0.044
>
> (>^Vb is textified ASCII of 193.62.22.98, another peer)
>
> Time to log a bug?
>

Yes, but what does the configuration file look like and why are all
those server addresses the same?

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

mayer@ntp.isc.org (Danny Mayer) wrote:

> > I can confirm this problem with ntpd-4.2.2, as I'm seeing this on one of
> > our GPS receivers which is having intermittent reception at the moment.
> > Here are ntpq -np outputs I happen to have logged from one of its peers
> > at consecutive two-minute intervals this morning:
> >
> > remote refid st t when poll reach delay offset jitter
> >
> > +193.62.22.74 .GPS. 1 u 20 64 377 5.780 0.087 0.055
> >
> > -193.62.22.74 .>^Vb. 1 u 12 64 377 5.780 0.087 0.043
> >
> > +193.62.22.74 .>^Vb. 1 u 2 64 377 5.834 0.049 0.031
> >
> > -193.62.22.74 192.36.134.17 2 u 57 64 376 5.834 0.049 0.044
> >
> > (>^Vb is textified ASCII of 193.62.22.98, another peer)
> >
> > Time to log a bug?
>
> Yes, but what does the configuration file look like and why are all
> those server addresses the same?

I picked the same line from four separate ntpq -np outputs, which were
taken at two-minute intervals, to show how the refid was changed to an
IP address but stratum was still 1, for a short period. I compressed
the output to show just the relevant part.

The ntp.conf for 193.62.22.74 proceeds as follows:

server 127.127.8.0 mode 7 minpoll 4 prefer iburst
fudge 127.127.8.0 time1 0.029

peer 128.86.8.123
peer 193.62.22.98
peer 193.62.22.90
peer 193.62.22.82

server ntp0.linx.net
server ntp1.linx.net
peer ntp2.usno.navy.mil
server ntp2.sp.se
server ntp1.mmo.netnod.se

driftfile /usr/local/etc/ntp.drift
enable monitor

restrict 127.0.0.0 mask 255.0.0.0
restrict ::1 mask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
restrict -4 default nomodify nopeer notrap limited
restrict -6 default nomodify nopeer notrap limited

restrict 128.86.8.0 mask 255.255.255.0 nomodify notrap
restrict 193.62.22.82 mask 255.255.255.255 nomodify notrap
restrict 193.62.22.98 mask 255.255.255.255 nomodify notrap
restrict 193.62.22.90 mask 255.255.255.255 nomodify notrap

# swathe of other restricts

--
Ronan Flood
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)