[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

More information about the Ecos-discuss mailing list