Clock and Hardware Timer usage

[Joel Sherrill]

Cedric Aubert wrote:
> 
> 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

The timeslice timer you refer to is simply a couter of 
ticks in the task's TCB.  I guess in theory there could
be an advantage to scheduling a separate ISR for that 
but I don't know if it is worth it since you would have
to reset the timer for each timeslice reset.  And because
RTEMS supports multiple threading APIs, this would occur
at seemingly random times.

I think separating out this functionality from the
timeout/interval timers would be a mistake for RTEMS.

> 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.

As a counter that's an OK concept.  RTEMS currently bases
much more on "ticks".  A tick can trigger a number of events.

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

To simplify math, would this RTC tick source produce a 1 Hz 
tick?

Remember that RTEMS has "interval timers" and "TOD timers".
You can schedule an event for a "when".  And that is 
(I think) always considered to be a second boundary.  
See rtems_task_wake_when() and rtems_timer_fire_when() for
examples.

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

But the rules for when the timeslice is reset would require
fiddling with the timeslice timer quite frequently.

And tasks don't always start with a complete timeslice.  It
varies based upon the API rules.

> 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

But all you are doing at each 1 ms boundary for timeslicing
is decrementing a counter.  

Having a more accurate TOD is a big deal.  And having the
ability to update TOD separate from interval timers could
be a big deal.

Right now, cpukit/score/src/coretodtickle.c is assumed to
run once per second.  It is scheduled using the ticks 
watchdog chain.  Having the ability to have a 1 Hz 
separate event to update TOD and getting partial seconds
from a HW device might be an improvement.  It would trade
off the overhead of managing the per_second_handler with
the overhead of taking another interrupt once per second.

I have always had a gut feeling that supporting a varying 
HW interval timer that we could reprogram based upon the
number of ticks until the next event would be the biggest
win.  Then there wouldn't be any "tick interrupts" until
you really had one.  The cost would be that any time the
head of the ticks chain was altered, the HW timer would have
to be reprogrammed.  With TOD processing enabled, this could
reduce the interrupt rate for ticks down to once per second
with no other events.  

I suppose it is also possible to change the TOD behavior so
it is more optional.  Right now, it is always running even if
no onen ever uses it.  Then 

> > 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.

I don't think timeslice management is near the burden you
think it is.  


> > 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. :-)

Doubtful. My explanation is probably not that clear given
the complexity of the subject and the number of possible
design solutions.

> > 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

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985