Ummmm, ntp is saying loud and clear that it's in trouble.
You just need to know how to interpret its wails.;)

xntpdc macbsd.jpl.nasa.gov
xntpdc> loop
offset:               967.201641 s
frequency:            512.000 ppm
poll adjust:          -30
watchdog timer:       58 s


xntpdc> kern
pll offset:           190160 us
pll frequency:        512.000 ppm
maximum error:        1014400812 us
estimated error:      1014368320 us
status:               0001
pll time constant:    4
precision:            1 us
frequency tolerance:  512 ppm
pps frequency:        0.000 ppm
pps stability:        512.000 ppm
pps jitter:           200 us
calibration interval: 4 s
calibration cycles:   0
jitter exceeded:      0
stability exceeded:   0


See those offset numbers? you're waaay out, and the pll is hosed.


I still dont see how to use teh frequency-locked loop (FLL) instead,
but since your clock is drifting around, that's what you want.
Maybe if you edit the flags word in ntp.drift to or 0x8 into the
second value, and kill and restart xntpd.

I hacked up some code to implement TIOCDCDTIMESTAMP for the com
driver; I can send a patch to any mac68k wizard who wants to
add it to the Mac serial driver (zs?).
Calling hardpps() couldnt hurt, either.