Ok, thanks, I am planning on reading the free running timer for now to
measure more exactly the time between counter readings and thus
calculate a fairly accurate frequency (speed of train). I think I can
easily get 1/10 of 1 percent accuracy for right now, which is more
than I need. I just don't like writing hardware specific code that
needs to be tweaked for different platforms. But, my job is to make
software that behaves correctly, even if I have to write hardware
specific code.
These little Arm boards are quite impressive. These little problems
are not that big of a deal, though I do look forward to improvements
every year. This time next year I expect gettimeofday() to work as we
would like it, and I expect the system time to be at least as accurate
as the crystal, hopefully, typically less than 1 second drift per day
at room temperature, maximum 2 seconds.
Don.
On 4/18/06, 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
>
>
> Visit your group "ts-7000" on the web.
>
> To unsubscribe from this group, send an email to:
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
> ________________________________
>
--
Dr. Don W. Carr
J. G. Montenegro 2258
Guadalajara, Mexico
+52-333-630-0704
+52-333-836-4500 ext 2930
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/
|