Re: [ECOS] Changing system timer resolution

[Nick Garnett <nickg at redhat dot com>]

Jonathan Larmour <jlarmour@redhat.com> writes:

> I think some care would need to be taken that overflow, underflow and loss
> of precision is avoided though - there can be both very big and very small
> numbers involved! Look at the hoops the "clock convertors" have to go
> through in kernel/current/src/common/clock.cxx for example! Although it
> wouldn't be as extreme as that fortunately.

Well, any public conversion routines should clearly use the clock
convertors, and not reinvent it all. The POSIX library does exactly
this. 

> I think we are pretty close to that in the delay_us function (currenbtly it
> is purely a busy poll). The only problem is that that function doesn't have
> an exposed (kernel C) API. As Jurica mentions, perhaps gettimeofday() would
> be adequate, although by doing that, you'll probably pull in POSIX baggage,
> so for now a kernel C API function may be better. "All" it would have to do
> is call CYGACC_CALL_IF_DELAY_US(usecs) from hal_if.h. Although that does
> rely on virtual vector support. Hmm...

The issues in getting a better-than-interrupt-frequency clock
resolution are many and complex, it is not amenable to a quick fix,
but requires a major restructuring of the whole eCos
timer/clock/alarm/timeout mechanism. I would not like to see some
ad-hoc implementation cobbled together to do this. hal_delay_us() is
designed to operate only in polled systems, where interrupts are
disabled - either in redboot or device driver ISRs. If hal_delay_us()
disabled interrupts to access the timer hardware, it can have a
serious effect on interrupt latency. If it does not, then other
interrupts and timeslicing will render it wildly inaccurate and
useless for the purpose proposed.

> 
> > > > Things like TCP and DHCP could then be written so that they
> > > > work with any system tick resolution.
> > > >

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.). If not, then the programs should be
changed to do so. We should not just fix up poor uses of
cyg_thread_delay() etc.

Many other test programs use a short call to cyg_thread_delay() just to
let other threads run. These uses probably do not need to be fixed
since they do not rely on the actual duration of the tick to work.

> I think I'd probably accept a (carefully written) patch avoiding the
> problems I mention above.
> 

What we can do now is add a simple convertor that takes a time in
seconds and nanoseconds and converts it 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.

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK