I thought I'd chime in here as the manufacturer of this hardware (TS-7200).The TS-7200 design uses a 14.7456Mhz quartz crystal accurate to 50-100 PPM. The 14.7456Mhz is digitally divided to 32768Hz by a CPLD and fed into the CPU which uses it to generate a 64Hz kernel tick. There is no PLL anywhere in that path that can add any extra error above 50-100PPM. In early versions of Linux for this processor, the authors naively tried to reach 100Hz with programmable timer hardware that could only hit something like 100.03Hz which added significant drift. There is a 983040 Khz internal timecounter (14.7456Mhz / 15) that can be used to increase resolution between clock ticks.
I can offer to RMA Ken's TS-7200 and have someone test its crystal with a accurate frequency counter out here. The pins are very easy to get to. However, I really doubt its the hardware. The way these crystals fail is they stop oscillating altogether. Usually, thats traced down to being internally shattered from being dropped.
There is an optional battery backed RTC which is identical to a x86 PC RTC on the TS-7200. This RTC is only precise to 1 second. Hopefully, its still only read once at startup and never looked at again. It has its own 32Khz oscillator that is actually more accurate than the 14.7456Mhz crystal.
In Linux, we have had issues with missed ticks in the past causing drift. To identify this, we instrumented low-level kernel interrupt code with independent checks against the 983040Hz free-running timer to see if the delta between ticks (hardclock() IIRC in NetBSD) was significantly greater than 1/100th of a second. Once we saw this was happening, we were able to identify the rogue drivers that disabled irqs for too long or the device on the PC104 bus that was very slow and held the ISA_IOCHRDY signal for too long. Another suggestion I would have is to try an older NetBSD kernel. I am pretty sure I had tested time drift (since we were fighting it simultaneously in Linux at the time) during the initial port and I'm pretty sure I didn't notice obnoxious drift beyond what I expected. I committed the bulk of ep93xx and TS-7200 code in 2004 and there has been changes since then that I do not recognize. Specifically, the addition of the timecounters(4) API and it looks like somebody added support for non-64HZ tick rates.
//Jesse Off M. Warner Losh wrote:
In message: <200812100356.mBA3uccU000394%ginger.cmf.nrl.navy.mil@localhost> Ken Hornstein <kenh%cmf.nrl.navy.mil@localhost> writes: : >What you are describing here is a frequency error. ntpd adjusts both : >the phase of the clock, and its frequency. Usually the initial : >inspection period is sufficient to get the initial estimate to within : >a tens or hundreds of microseconds, and the frequency to with a ppm or : >two (later it gets much better). This means in the 1000s that your : >logs showed the clock should have drifted on the order of maybe 1ms. : >Instead, it drifted by 200ms, 100x too much.: : Sigh. I don't know how to explain this any clearer. : : RIGHT AFTER the clock is stepped, ntpd reports the time being off ... by: a lot (that's the 100-900ms I was talking about). During the 15 minutes : or so that ntpd takes to reset itself, the this clock offset changes very : little. I don't understand how that can be a frequency error. If it was : a frequency error, it would never get in sync, but it does.: : Am I just not explaining this well?The log that you posted showed 1000 deltas in time between the steps. I've done a *LOT* of ntpd work with custom reflcocks and timing hardware. Your problems look exactly like problems I've had with systems that have frequency errors. To get to the bottom of this: o Turn off ntpd. o Do an ntpdate. o wait 10s o Do an ntpdate. What are the results? Warner