🚀 go-pugleaf

Lars> I am not sure that the SLEWALWAYS code has ever been tested. (I
Lars> certainly didn't do so when I was hacking xntp to version 3.) On the
Lars> other hand, it does seem like it ``ought to'' work --- it's not that
Lars> complicated.

I'm a little worried about what happens if the clock drifts too far
for adjtime to be able to cope reasonably.

Lars> It does seem that you need something like SLEWALWAYS, or perhaps a
Lars> variant that uses gettimeofday to get to the nearest second and leaves
Lars> the residue in sys_offset. Since it is you who needs the feature, it
Lars> is probably up to you to get it to work.

This is what I was thinking of doing.  I'm willing to do the coding,
but I'm worried about breaking NTP in the process, as I don't really
understand how it works.

For example, if I use a variant of settimeofday to get to the nearest
second, will xntp be able to deal with the rest of the offset with
adjtime?  As the code is now, it looks like it will attempt to step
for any offset greater than 128ms, and may never get in sync.  Also,
the comments warn about increasing CLOCK_MAX above 500ms, which is the
minimum that I would need (and, even then, I could end up stepping a
lot).

What sort of tickadj values are reasonable if one is reliant on
adjtime? 

Have you any hints about what I might try, or things to avoid?
What is the best way of testing an NTP server?  (I don't want to start
running a flaky Stratum 2.)
--
Alan