Jim
As we say round here "You got me!" I don't have an explanation:( I vaguely
remember some early posts and I thought that you had changed your divider on
test for an optimal value? Although on reading the adjtimex man page
(followed own advice and rtfmed;)) it may be that the kernel internals will
work with whatever the clock gives it and adjust accordingly. The values
from adjtimex -p would presumably take account of the lack of precision in
the stock gettimeoffset.
Bob
On Tuesday 18 April 2006 23:17, Jim Jackson wrote:
> 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
>
>
>
--
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/
|