This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Changing system timer resolution


Jonathan Larmour <jlarmour@redhat.com> writes:

> Nick Garnett wrote:

> > Well, any public conversion routines should clearly use the clock
> > convertors, and not reinvent it all. The POSIX library does exactly
> > this.
> 
> The convertors are primarily intended for converting ticks of a certain
> frequency into ticks of a different frequency, but I suppose this could at
> least make something that works.

Not at all. Take a look at the POSIX code for how they are used to do
arbitrary time conversions.

> 
> Except that functions like gettimeofday() are meant to be fast, and the
> paranoia of the clock convertors (because they don't know the order of
> magnitude of either resolution - the convertor or converted) is overkill in
> this situation.

There are no execution time requirement on gettimeofday(), it is not
meant, in UNIX/POSIX, to act as a realtime timer.

All the paranoia is in creating the set of factors to use, which you
do once. The actual conversion is just a set of multiplies and
divides, and is as fast as the ALU can go.


> > 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.
> 
> No it isn't! :-) Have a look in hal/common/current/src/hal_if.c.

There is no way that the code there can deal with the accuracy issues
I mentioned. It does not cope with what would happen if this code were
preempted for more than one (eCos clock) tick.

> 
> The only optimization would be what I suggested before which is to delay
> for a number of whole clock ticks first until woken up, before using
> HAL_CLOCK_READ in a busy loop type way.

This does not address the problems I mentioned, particularly the
tradeoff between interrupt latency and accuracy of the delay.

> 
> > > 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.
> 
> I thought we were talking about _sub_-tick resolution? And gettimeofday-ish
> functionality?

The origin of this discussion was the lack of a mechanism for
converting real time intervals into ticks, and the assumptions of some
test programs that 1tick == 10ms. I was suggesting that we could fix
that problem fairly easily. The rest is much more complex.

Sub-tick resolution is not something we can address now, I would
oppose the incluson of any quick fix to do this. If users want to
cobble something together themselves, so be it, but I don't want it in
the main sources. The kernel APIs are all designed to work in ticks,
adding random bits of API that work in other units is inconsistent and
would be incompatible with future plans.

As far as gettimeofday()-like functionality is concerned, that would
require proper wall clock support, which is not present in all
platforms. 

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]