I knew about the priority problem, but. . .

At 12:11 PM -0800 3/25/98, Jonathan Stone wrote:
>This causes macbsd to lose clock-tick interrupts (up to 5%), killing NTP.
>here is just _no_way_ NTP can handle sustained loss of clock ticks.
>It creates about 3 orders of magnitude more jitter than NTP is
>designed to handle.
>
>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?

>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.

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.

>Eliminating clock-tick loss (thus improving NTP) has been lower
>priority than getting Netbsd/mac68k to actually work on msot
>hardware. I'd hope a fix would show up "soon".  Ask your friendly
>portmaster or Bill Studenmund for an estimate.
>
>If this is really causing problems, maybe doing the poll at the tail
>of the serial-interrupt routine (and pulling up for) 1.3.2 is
>worthwhile.

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.

Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu