It also says,
"The frequency file is updated at intervals of an hour or more depending on the measured clock stability."
I've never seen the file updated once it's made, and sometimes it doesn't get made if it's not there to begin with.
Also, I've noticed two bugs. One is Apple related -- if the machine goes to sleep, on wake up the clock will be way off, and need a stepping. However, ntpd wants to assume that the entire drift change occured during the last polling interval (generally around 64-4096 seconds), rather than the total time the machine was asleep. Ntpd isn't restarted when the system wakes up and the clock is known to be in error.
This has been seen since 10.4.3, and is still present in 10.5.5; it causes two clock steps (at least) on wakeup -- one to correct the clock, and give ntpd an inaccurate, high drift value; the second once it has corrected the drift but restepped the clock again.
In 10.4, ntp was keeping the drift file up to date. (In fairness, I don't recall if I was using the apple ntp, or if I had compiled the tarball. I do know that I had gotten both "burst" and "iburst" to work, and they do NOT both work in 10.5.5. "Burst" definitely is a no-op, and I'm not sure that "iburst" works or not.)
The second bug is definitely an ntpd bug, but I don't know where to report it. If the "clock out of range" time is more than 900 seconds, the next update automatically sets the clock. Even if the current time interval is more than 900 (eg, 1024 seconds), which means that if the clock is stable enough to get to 1024, then any error automatically alters the clock, without any "Hey, lets wait and see if we get a second sample that's valid".
Oddly, that bug has caused me problems in two cases: Dialup (file downloads saturate the line), and wireless (intermittent connections make nice random, occasional delays ...)
