Don
Going back to my earlier comment, I believe the stock kernels, -ts8 and -ts9,
don't have the gettimeoffset function in them. This means that although ntp
is correctly instructing the kernel with the adjtimex calls, the kernel isn't
really implementing this. Without this function and continuous ntp updates
you will get drift exactly as Jesse outlines.
Look in arch/arm/kernel/time.c and you will see the default is to use a
function dummy_gettimeoffset which just returns 0.
Unless the kernel is patched as I indicated earlier then no "tweaking" of the
clock by adjtimex will be effective.
You can test if gettimeoffset is functional by repeated calls to gettimeofday
and looking at the usec value. If the dummy function is being used then the
value will always be on a 10 millisecond boundary or very close to it.
The adjtimex and the resultant tweaking of the clock values are designed to
compensate for crystal clock drift and other inaccuracies. Just look at any
standard PC and the time drift you can get if ntpd or similar aren't being
used. I have come across PCs with up to 60 seconds drift in a day if they
weren't referenced back to a clock src such as the rtc. If you can tolerate
slight jumps, our application can't which is why we fixed the kernel to
implement adjtimex, then reading the rtc on a regular basis with say cron and
updating system time works.
Hope this helps
Bob
On Tuesday 18 April 2006 20:14, Jesse Off wrote:
> > Your goal should be Arm boards that are within 1 second per day on
>
> the
>
> > system clock. I would imagine, with the hardware you have, you
>
> could
>
> > achive that with a little creativity, it is a matter of software.
>
> 1 second per day is beyond what can be done with today's common
> crystal oscillator technology. You would have to go with expensive
> temperature compensated crystal oscillators or rubidium
> oscillators. One may be able to calibrate a single unit at a
> constant temp better than 50 PPM, but crystals also drift with age--
> it would be impossible for a manufacturer of hardware to guarantee a
> more accurate clock than that of the crystal manufacturer and
> crystal manufacturers say 50 PPM.
>
> The timing drift in this instance is excacerbated by software,
> specifically the Linux kernel and its legacy of a 100Hz tick rate.
> We cannot take ownership of all Linux problems just like one cannot
> expect to be able to contact the USB mouse manufacturer when a mouse
> pointer locks up on a PC screen. We fix what we can, but we can't
> get any better accuracy currently with Linux. I believe another one
> of our customers in this forum actually use the TS-7200 in a NTP
> server product they designed-- you may want to contact them for any
> patches they may have made to the kernel.
>
> GPS units have very precise timing. We have a PC104 daughterboard
> designed for a customer that includes a GPS unit that extracts an
> extremely precise 1Hz and 10000Hz signal from the air. This
> solution would still be much cheaper than a rubidium oscillator.
>
> //Jesse Off
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
--
V +44 (0) 1296 747667
F +44 (0) 1296 747557
C +44 (0) 7860 406093
Diamond Consulting Services Ltd
Dinton
Aylesbury
Bucks, HP17 8UG
England
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|