I'm working on it. See http://phk.freebsd.dk/rover.html for what *can*
be done if you try, and have a few hundred dollars in timekeeping
hardware added to your PC (upshot: he currently can't distinguish the
performance of his PC from a Cesium atomic frequency standard, and is
looking to borrow one so he can measure more accurately), and I'm free
to steal his ideas.
I'm trying for good performance from existing PC hardware though.
Thanks for the heads-up on the even crappier main oscillators.
(If you can get an Allan variance curve out of the manufacturers,
it would be very nice.)
For folks who don't know, a typical current PC has two crystals.
a 14.318 MHz "colour burst*4" crystal at 315/22 MHz that drives the
programmable timer (IRQ 0) directly, and the processor's 60/66 MHz
clock and the serial port's 12 MHz clock through a PLL chip.
Secondly, a 32768 Hz crystal for the battery-backed clock. This is
actually shaped like a miniature quartz tuning fork, and is a low
frequency to reduce power consumption in the attached circuitry.
Every quartz wristwatch in the world runs off such a crystal.
Although theoretically the higher-frequency crystal has less loss
than the tuning fork (which has arms waving in the air), which results
in greater frequency precision, in practice the tuning forks are
optimized for timekeeping and tolerances are tighter, while the higher
frequency clocks are built to just (barely) make it within spec.
The link on the rover.html page to John R. Vig's paper will tell you
more than you probably ever wanted to know about Quartz oscillators.
Anyway, Alan Cox was nice enough to point out to me that there are some
embedded systems where the RTC interrupt is wired to RESET rather than
IRQ 8 so the system can use it as a watchdog timer. This makes using
that source for interrupts somewhat impractical. The code has to adapt
to a wide variety of brokenness. (It's still doable, although precision
suffers.)
The idea I'm working on is to use the cycle counter as much as possible,
but to calibrate it against the battery-backed RTC (which will also
detect all kinds of APM events), and calibrate that whole mess against
external sources with NTP.
I've been working on code to take RDTSC readings from successive interrupts
and strip out the noise. Since the noise is one-sided (interrupts are
only ever late, not early), averaging doesn't get rid of it too well.
Since the noise depends on what you're doing (when the make -j finishes,
things change), using averages isn't even stable, let alone precise.
Right now I'm trying to deal with SMP issues. If any SMP hackers would
like to guide me through SMP interrupt handling on *all* Linux platforms,
I'd like to ask a few questions. Please email me. (E.g. I don't understand
the APIC stuff at all.)
-- -Colin(P.S. This all started when David Miller complained to me about how long secure TCP sequence number generation was taking. I looked, and gettimeofday() was taking half of the time. So I set out to fix it. Fixing it *right* is a lot harder than it seems.)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html