Arnold Schekkerman wrote:
Checking my memory: looking in the RFC's, curious if I remembered from an old
spec.
and what the changes are. I found something tricky.
Searching in the (now obsolete) RFC 1305, for unsync only finds stuff related to
leap indicator (so far my memory is still fine :-) ).
Doing the same search in RFC 5905 gives an interesting result besides the table
Rob
mentioned: section 11.1 "... then the leap is set to 3 (unsynchronized) and
stratum
is set to MAXSTRAT (16). Remember that MAXSTRAT is mapped to zero in the
transmitted packet."
So, stratum 16 means 'unsync' internally, but is never transmitted over the
wire!
Ok... in my memory, leap=3 was the KOD reply. Something different. But it
appears to be more
complex and also it has been changed.
The NTP RFC (present and past) is a tricky (confusing) specification as it uses
the
same names for internals and for fields of NTP-packets sent over the wire (like
'mode' in section 3, which is even used wrong in figure 10 (no errata yet)).
To add to possible confusion, Figure 22 defines "Packet Type 6" *also* as
'unsynchronised'... I've not read further, so I am unsure if that is sent over
the
wire or not.
In the past, the tendency when reporting problems often was "read the book, the book
is right"
and when reporting bugs "the code does what the book says and the book is
right".
However, this appears to be improving lately. Lots of longstanding bugs have
been fixed.
The problems currently experienced (DDOS) are partly caused by the omission of
a correct
and usable example (default) configuration file. This also caused the
widespread mis-use
of the LOCAL clock, which then can cause the problems we are discussing here.
It looks like the project team now realizes that a default config file (and
maybe also a default
startup script?) could improve the average quality of installations, and thus
the quality of the
service. 10 years too late, but hey! Better now than never.
It seems to me the monitor would never receive stratum 16, but Ask wrote it does...
It could be that the server being used is not the reference ntpd and behaves a
bit different than
ntpd does.
Rob
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
