[ECOS] Changing system timer resolution
Grant Edwards
grante@visi.com
Mon Dec 3 08:10:00 GMT 2001
On Mon, Dec 03, 2001 at 11:40:36AM +0000, Nick Garnett wrote:
> They should work now. Any TCP/DHCP code that relies on times should be
> using the timing facilities provided in the network or POSIX APIs( e.g.
> select() nanosleep() etc.).
Excellent! My source tree is getting old and I hadn't realized this had been
done. Last time I looked at TCP stuff I think there was a hard-wired
definition of HZ, and I thought that changing the tick period would break
things. At one point (a long time ago) I did have my system tick at 1ms for
a while, but I wasn't doing any network stuff at the time.
> If not, then the programs should be changed to do so. We should not just
> fix up poor uses of cyg_thread_delay() etc.
Someday soon I'm going to try switching my tick interrupt to 1ms as an
experiment. It'll eat up a bit of CPU time, but I've got customers who want
1ms resolution on their alarms.
> What we can do now is add a simple convertor that takes a time in seconds
> and nanoseconds and converts it to ticks.
It sounds like that would solve most of the problem. If I were getting to
pick, I'd also like a converter that converted an integer value from either
milliseconds or microseconds to ticks.
> A convertor in the opposite direction would be good for completeness, but
> is not as useful. There are already such convertors in the POSIX package.
--
Grant Edwards
grante@visi.com
More information about the Ecos-discuss
mailing list