By way of followup to my earlier e-mail, I just watched it crank up to
>128 ms offset and reset itself:
remote refid st t when poll reach delay offset jitter
==============================================================================
193.52.184.106 .INIT. 1 u 90 256 17 104.394 9.802 3.372
*145.238.110.49 .1PPS. 1 u 86 256 17 91.070 9.716 3.010
65.169.131.137 65.75.183.220 3 u 8 16 101 86.489 21.743 63.738
212.127.156.199 193.120.10.3 2 u 8 16 100 23.432 25508.7 39.185
80.171.74.70 66.229.200.200 2 u 8 16 100 134.291 2083.87 27.846
82.82.119.133 141.82.30.252 3 u 7 16 100 262.728 202.356 1.323
65.12.208.237 216.27.160.99 2 u 6 16 100 0.015 28153.6 41.638
67.40.124.209 24.130.207.189 2 u 5 16 100 262.554 78.757 0.431
...
I don't know what it's doing, but it's NOT running a working ntpd!
The offset drifts up to NTP's CLOCK_MAX step threshold and then resets
itself.
I confess I'm a little confused trying to find the admin. The machine's
reverse DNS is ns1.kamino.fr, although it also has forward names ntp, pop,
and kam00.kamino.fr. Now, kamino.fr the company lists an address is in
Grigny, just outside of Paris, but their servers are all in 65.98.80.*
and 216.32.94.*. Which are Pegasus Web Techlogies in New Jersey, and
Layered Technologies in Texas, respectively.
Anyway, it boils down to I have no idea who to contact.
By the way, is anyone else beside me noticing a persistent -16 ms offset
to 64.236.96.53 (nist1.aol-va.truetime.com)? It's just barely possible
given the RTT of 37 ms I'm measuring, but hard to believe.
But then, I guess I shouldn't complain too much - I just recorded
*repeatable* time offsets from 750 to 1000 ms from time-b.nist.gov.
(Between UTC times 2005-08-22 23:25 and 23:45, MJD 53603 second 85000
if you want to look in any NTP log files).
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
