Thanks for all the suggestions.

Yes, that message came from ntpd.  Sorry I snipped too much context 
while trying to avoid clutter.


The clocks are solid when the network isn't being abused.

I'd expect ntpd to work better than this if the network gets trashed 
but the local clock is reasonably good.

I'll try to find a simpler test case.  Perhaps Jason's new interrupt 
statistics (for Alpha) will help sort this out. 


Here is some more info that might help.  This pattern is reasonably 
common - that is the clock takes a big jump forward and then a small 
jump back.

Jun  6 00:07:36 foraker ntpd[178]: time reset 0.989102 s
Jun  6 00:07:36 foraker ntpd[178]: synchronisation lost
Jun  6 00:31:16 foraker ntpd[178]: time reset -0.401379 s
Jun  6 00:31:16 foraker ntpd[178]: synchronisation lost

Here is what I think is going on.

  Before it takes the jump, it's missing many clock interrupts.

  In an attempt to keep the time right, the clock-speed knob is set 
  to make the clock go faster to try to keep up. 

  The big jump fixes the time, but it doesn't reset the knob.

  The test ends so that interrupts are no longer getting lost.
  
  The knob is adjusted too fast so the clock runs too fast. 

  It overshoots, and gets reset back.

  By that time, the knob has been set back close enough to normal. 


(I guess I need a script to track the knob.)