[ntp:questions] Re: ntpd+TRIMTSIP+PPS keeps clockhopping - workaround

Kevin MacLeod kevin-usenet at horizon.com
Sun Feb 13 18:22:10 UTC 2005


I tried a few things.  I tried playing with some of the averaging
enabled by flags1 and flags2 on the PARSE driver, but then found that
was old documentation and it isn't there.

I tried cranking the step threshold down to 0.1 ms so the clock
would ignore the hops, but that made a mess of initial convergence
and didn't solve them, degrading timekeeping.

Then I tried hacking source code.  I hacked TRIMBLETSIP_ROOTDELAY in
refclock_parse.c from 0 to 0.025 (25 ms) to try to give it a larger
uncertainty window so it would stop getting discarded by the intersection
algorithm.

That appears to be working for now.  It's been almost 24 hours
(22:22, to be precise) since the last clock-hop.  That's happened
before, but it's encouraging.

The problem is, it still clock-hops during startup, before any of the
network peers are valid.

Because NTP tends to use the selected peer's poll interval for
everybody, if I have the refclock poll interval small, it pings
the network peers too often.  So I have them set to minpoll 128
or 256.  This makes initial acquisition slow.

While no network peers are available, what happens repeatedly is:

- serial timecode reachability reaches 17.
- PPS starts acquiring.  When it reaches 17, then
- serial timecode is declared a falseticker, which stops
  incoming PPS.
- Then PPS reachability goes down until it's excluded
- serial timecode becomes the selected peer again
- and the cycle repeats.

In the steady state, things alternate on successive polls between
- PPS reachability 125, PPS peer selected, PARSE declared falseticker, and
- PPS reachability 252, PARSE peer selected

This causes some impressive instability until a network peer comes
on-line and tames the intersection algorithm.

This indicates, to me, that my attempt to enlarge the confidence
interval was not completely successful.  Would increasing the
refclock's delay (as opposed to rootdelay) work better?  Is there
a way to do that?  Is there anything else I should be tweaking instead?

I just want to say "The serial timecode is very noisy, so don't
be too narrow-minded about the valid range when intersecting it."

I'm not sure *why* it's noisy, and that might be a matter for
exploration, but that's less important as long as PPS works.



On a related note, it is very annoying that every time I change some
configuration option and restart ntpd, I have to wait a long time for
things to settle down before I can see the effect.  Supposedly, it's
possible to do run-time reconfiguration, but I've tried repeatedly and
never got it to work.  Can anyone tell me what's going wrong?

I have the following ntp.conf settings:
restrict 127.0.0.1
keys /etc/ntp.keys
controlkey 1
controlkey 2
requestkey 1
requestkey 2

And /etc/ntp.keys contains some random ASCII 8-character strings
1 M 11111111
2 M 22222222
3 M {n_$~iGi
4 M I%dL"9J,

(I have masked the real, live, keys 1 and 2, since I'm positing this in
public, but you get the idea.  They're generated by feeding the output
of /dev/urandom through an isgraph() filter.)

But trying to set something always fails.
E.g.:

$ ntpq -n
ntpq> as

ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 49205  9455   yes   yes  none  candidat  clock expt  5
  2 49206  9714   yes   yes  none  pps.peer   reachable  1
  3 49207  9314   yes   yes  none   outlyer   reachable  1
  4 49208  9314   yes   yes  none   outlyer   reachable  1
  5 49209  9414   yes   yes  none  candidat   reachable  1
ntpq> rv 49207
assID=49207 status=9314 reach, conf, sel_outlyer, 1 event, event_reach,
srcadr=216.53.131.66, srcport=123, dstadr=192.35.100.1, dstport=123,
leap=00, stratum=2, precision=-14, rootdelay=38.635,
rootdispersion=11.017, refid=129.6.15.29, reach=377, unreach=0, hmode=1,
pmode=2, hpoll=7, ppoll=7, flash=00 ok, keyid=0, ttl=0, offset=-0.915,
delay=8.988, dispersion=8.442, jitter=0.290,
reftime=c5ba11bf.23d15000  Sun, Feb 13 2005 12:49:51.139,
org=c5ba1213.2bed8000  Sun, Feb 13 2005 12:51:15.171,
rec=c5ba1213.2d57e0c8  Sun, Feb 13 2005 12:51:15.177,
xmt=c5ba1213.2ae7c75b  Sun, Feb 13 2005 12:51:15.167,
filtdelay=     9.19   10.36    9.07    9.67    9.11    8.99    9.17    9.10,
filtoffset=   -0.93   -0.27   -0.82   -0.57   -0.81   -0.92   -0.99   -1.06,
filtdisp=      0.06    2.01    3.92    5.84    7.77    9.72   11.66   13.58
ntpq> writevar 49207 dstport=124
Keyid: 1
MD5 Password: 
***Server disallowed request (authentication?)
ntpq> writevar 49207 keyid=3
***Server disallowed request (authentication?)
ntpq>

Obviously, I entered the password, exactly as it appears in the
ntp.keys file.  I also retried with keyid 2.

I don't see any related error messages in the ntpd log file.
Is this supposed to work?

Thanks for any suggestions.



More information about the questions mailing list