>>That's  a Definitive Answer of the cause of the problem.
>>I thought it was going to be in the release notes for 1.3.1.
>
>If that's the case then why does NTP keep running for 5 days and report
>that it is in lock at stratum 3 like it should be?  Why is the time
>reported by ntpq:rv different from the time reported by the date command?

I dunno.  Does the mac68k have vmstat -i or evcounters?  I'd watch the
interrupt rate with vmstat -i (using a wristwatch or stopwatch) and
see what devics are interrupting, and how load modulates the
clock-tick loss rate.


A count of dropped ticks would be a useful diagnostic tool, if theres
any way to detect them cheaply.


>>The relevant people know about this.  To work around the hardware
>>misdesign in software requires kernel changes (short-term quick way:
>>poll for pending clock ticks at the end of the zs driver. Long-term
>>clean way: rework SPL and interrupt processing completely).

>I had an exchange with Scott R about this a while ago and we agreed that a
>good workaround would be to create a 1PPS interrupt somehow that could be
>fed to NTP which could use it to "fix" the local clock.  From what you say
>I guess this may not be a viable solution after all.

All the NTP machinery is in the kernel already, all you need to do is
get a high-priority (or at least very low jitter) interrupt, build a
kernel with options PPS, and add a call to hardpps() when the PPS
signal goes off.  That would be really cool.

I've never heard of anyone using PPS with a clock drifting as badly as
5% - 50,000 ppm.  I dont see how the PLL would ever stabilize within
its limits (but I'm not a control theorist, I dont even play one on TV).

IIRC, if the PLL on the local clock never stabilizes, xntpd is never
going to discipline the system clock to NTP's idea of the time.  So
this may not help you.  But the PPS support would be really cool to
have anyway ;)

>Also FYI I have nothing on the serial ports at all so that isn't where the
>blockage comes from on my machine.  Could be lots of other things though.

IIRC, the clock has the lowest hardware priority of all.

>I can stick ntpdate in a cron job like everyone else I suppose.  Just seems
>a pity since I have so many good tickers around to sync from.

yes, indeed,  life is hard for thea time-vultures.