Clock and Hardware Timer usage

[Cedric Aubert]

Hi

Thanks for your respond.

> I think this is a possibility I have considered in
the past.
> There are a handful of possible requirements here so
let's
> see if I can state them all and see what the goal
is.
>
>   + one timer for wall-time/TOD updates
>   + another timer for timeouts
>   + syncing wall-time TOD to RTC HW

In fact, I think, but may be I am wrong, that one of
the best solution will
be :

- one timer for timeslice (only for periodic task on
timeslice without
preemption)
- one timer for timeouts
- TOD should not depend of the tick count, but only on
RTC + the current
value of a timer

To be sure I am right in my explanation, ticks for me
it's the number of
timer IT(Timer IRQ) since the
system boot up.

So each time we need TOD we read the timer, no need to
read again the RTC or
may be sometime.

for the both timer, the "timer for timeslice" should
have a periodic IT for
example 10ms or other
depend of need.

The "timer for timeout" should not have a period IT
like the first, so no
ticks count for this one.
They are no sence to count a number of this timer IT
if it isn't periodic.
But use this timer
only for the upper priority timeout (of course the
shortest).

And an other solution, should be very good to lower
performance system, it's
to have only the
"timeout timer" and program the timeslice period with
a timeout like the
other timeout in fact.

Advantage :
- Only one timer (like now)
- Can have TOD the best resolution possible (timer
resolution can't do more
:-)
- Can have better resolution for timeout without
enought performance
deterioration

For example (with one 1ms timer step) :
- Timeslice period at 10ms
- Timeout at 1ms step
- TOD at 1ms

> A simple starting spot for a solution is to divide
the current
> rtems_clock_tick() into two routines (names are up
for discussion):
>
>   + rtems_clock_tick_TOD()
>   + rtems_clock_tick_intervals()

Still be period for the both, still have a performance
problem with
little CPU system.

> Leave rtems_clock_tick with its current behavior for
compatability.
> A BSP will either call the current tick or the pair
of the above if
> it has independent timers.

I don't really understand what you mean below, may be
my RTEMS knwonledge
is to poor. :-)

> The bigger problem is that there is an assumption of
one tick
> quantum and both delays and TOD operations are based
upon the
> same quantum.  It all goes back to the configuration
table
> parameter microseconds_per_tick.  I think you would
have to
> do some analysis to make sure that you don't have a
bigger
> problem.  It is possible that it might require two
time quantums
> to be specified.
>
> Also there is a "ticks watchdog chain" and a
"seconds watchdog chain".
> The processing of the seconds watchdog chain will
have to be tied to
> the TOD timer not processed as an element of the
ticks chain every
> "ticks per second".
>
> It sounds complicated but I think it is just a
matter of getting
> a few core things reworked correctly.
>
> --joel
>


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com