Re: Future time

Re: Future time

[Colin Plumb]

Regarding improving the clock handling...

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

Re: Future time

[Thomas Sailer]

For those living near germany, I have some
DCF77 receiver code (the german timecode transmitter
on LF, 77.5kHz) using the pseudo noise phase 
modulation sequence (read much more accurate than
the amplitude stuff).

Tom

-
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

Re: Future time

[Richard B. Johnson]

On 11 Jul 1998, H. Peter Anvin wrote:

> Followup to:  <Pine.GSO.3.96.980711034638.18184A-100000@delta.ds2.pg.gda.pl>
> By author:    "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
> In newsgroup: linux.dev.kernel
> > 
> > > Then, the SMP machines don't use these controllers at all unless the APIC
> > > is broken.
> > 
> >  But not all ia32 machines are SMP and these which are not have usually
> > the onchip APIC either absent or disabled.  Unfortunately...
> > 
> 
> Actually, the thing to use is the cycle counter if the CPU clock is
> anywhere near stable.
> 
> 	-hpa
But that's the point! In the near future, CPU clocks will only be stable
to about 2 percent because the next cost-cutting 'comsumerish' thingy
will be to replace quartz crystals with ceramic resonators.


Cheers,
Dick Johnson
                  ***** FILE SYSTEM MODIFIED *****
Penguin : Linux version 2.1.108 on an i586 machine (66.15 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.


-
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