"Henry B. Hotz" <hotz@jpl.nasa.gov> writes:

>First I thought the problem was that GENERIC kernels do not have options
>NTP turned on.  Now I have a custom kernel with that option and I am seeing
>the same problem other people have reported:  NTP thinks it's working, but
>it isn't fixing the local clock.
  ...
>Anybody got any ideas for where the problem is?

the problem is that the Mac hardware has a priority inversion: it puts
the serial port at higher priority than the clock.

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.

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

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.