ISR to task scheduling help

[Aaron J. Grier]

On Tue, May 28, 2002 at 12:42:57PM -0500, Joel Sherrill wrote:
> I haven't noticed any replies so will take some guesses.  :)

I used to follow up my own posts, but some people started thinking me
insane.  :)

> Is this the highest priority task in the system?

correct.

> Including any network servers?

no networking.

> Is there another no preempt task in the system?  

no.

> Ths clock tick processing is directly proportional to the amount of
> work required.  How many simultaneous tasks are doing timeouts, the
> number of timers, etc?

no timers running, one task blocked on an event read.

> Normally you will only decrement a single timer, but when they fire,
> there is work to be done.  And if a number fire on the same tick, then
> you get the spread.  Try seeing the variation in the length of time
> the rtems_clock_tick directive takes.  This will check out this
> theory.

the latency hit is happening somewhere in the scheduler.  I switched to
using a timer, and the delay became much more consistent, so I haven't
pursued it further.

and now following up to my own post:

> "Aaron J. Grier" wrote:
> > here's a distribution of timing from the clock tick handler, which
> > subsequently calls rtems_clock_tick().  each of the bins is 1/256th
> > of a clock tick.  (it's my sampling clock.):
> > 
> > {0 <repeats 147 times>, 1, 0 <repeats 69 times>, 2, 2142,
> >   0 <repeats 37 times>}
> > 
> > here's the distribution I see in the task:
> > 
> > {0 <repeats 60 times>, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1,
> >   0 <repeats 151 times>, 96, 0, 2026, 0 <repeats 21 times>, 15, 2,
> >   1, 0, 0, 0, 0, 0, 0}
> > 
> > aside from a tick of startup noise, the clock tick is tightly
> > clustered around bin 218, and I would expect to see similar
> > distribution in my task, but it's smeared.

for comparison, here is the distribution (at timer level) in the final
application, which includes three tasks and one other timer:

{0 <repeats 228 times>, 45, 196, 103, 0, 1, 0 <repeats 23 times>}

a lot nicer.  (you can ignore the overall timing shift -- it's tunable.)

the timer actually ended up being a better solution all-around: as I
discovered my hardware doesn't actually require being tickled every
clock tick, so a "one shot" timer ended up making more sense than a
rate-monotonically scheduled task.

-- 
  Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  aaron at frye.com