Bob,
I'm baffled by this. I'm using a ts6 kernel and a rebuilt busybox with
adjtimex. I ran the arm developemnet image with ntpd and used the results
to feed adjtimex. I then ran live tests and fine tuned it to give me
accuracy of 1 sec in 2/3 days in my environment.
Something appears adrift here, or am I not understanding this.
On Tue, 18 Apr 2006, Bob Lees wrote:
> 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
>
>
>
>
>
>
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/
|