> 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.
I just wanted to warn you that this probably won't be any different in
a year on the default flash load, despite what you may expect. We may
however have a new product based on another CPU in a year that doesn't
exhibit this behavior.
These boards have already been released and this issue with Linux has
been known for well over a year already. Moving the tick rate from
something other than 100Hz is not something casually changed. There
are too many people with products in the field for us to change this
now-- this isn't a simple "bugfix"-- its an unfortunate side effect of
the Linux design as it applys to this processor.
While changing the clock to 64Hz may please you in the short term, it
could possibly affect other people's designs by exposing latent race
conditions or other serious bugs since the timing of all process'
would be subtly affected. You probably would best either 1) lobby the
developers doing Linux 2.6 for a fix and be prepared to update boards
manually to 2.6, or 2) change the 2.4 (or pay someone to change) 100HZ
clock to 64Hz yourself, or 3) use a different operating system than
Linux that does not have this issue.
//Jesse Off
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/
|