RE: [ECOS] Re: DSR Scheduling Problem

[Jay Foster <jay at systech dot com>]

I still think that FIFO queuing of the DSRs is better than LIFO queuing,
because in the absence of any DSR priority information, the best that can be
done is temporal priority (ie FIFO).  This prevents the case (that I'm
seeing) where a lower priority ISR's DSR preempts a higher priority ISR's
DSR (the priority is lost in the LIFO DSR queue).

I located the kernel versions of the DSR code
(kernel/current/src/intr/intr.cxx), and discovered that there are two
implementations for the DSR handling (CYGIMP_KERNEL_INTERRUPTS_DSRS_LIST,
and CYGIMP_KERNEL_INTERRUPTS_DSRS_TABLE).  The default is to use the LIST,
which is LIFO, but the TABLE implementation is FIFO.  I switched my
configuration to the TABLE implementation, and my code works.  So a second
reason to use FIFO for the DSR LIST implementation is to match the behavior
of the TABLE implementation.

Jay


-----Original Message-----
From: Grant Edwards [mailto:grante@visi.com]
Sent: Friday, January 13, 2006 3:42 PM
To: ecos-discuss@ecos.sourceware.org
Subject: [ECOS] Re: DSR Scheduling Problem


> The test begins by transmitting data, which is looped back to the
receiver.
> It starts out with:
> 	TX ISR -> TX DSR
> 	TX ISR -> TX DSR
> 	...
> 	TX-ISR -> TX DSR
>
> Then I get the RX ISR during the TX DSR, which just schedules
> the RX DSR. However, the RX DSR does not run until 39 ms
> later,

And TX DSRs are running during that entire 38ms?

> resulting in an overrun error.  During this time period, the
> TX ISR and TX DSR continue their work transmitting the
> remaining data.  After all of the data has been sent, THEN the
> RX DSR runs.

It appears you don't have enough CPU time to run all of the
DSRs you want in the alloted time.

> Looking at the code post_dsr() and call_dsr() in
> hal/common/current/src/drv_api.c, I noticed that the DSRs are
> queued at the head of the list, and dequeued also from the
> head of the list.

Yup.  DSRs are scheduled in a LIFO manner. 

> This seems wrong,

It seems to work for everybody else. ;)

> as it can (and apparently does) cause DSRs to get delayed by
> other DSRs that are queued later.  Seems like it would be
> better to queue them on the end of the list and dequeue them
> from the head of the list, so that the DSRs would get run in
> the order in which they are queued.

If the DSRs that you're scheduling require 150% of the
available CPU time, then something's going to fail.  

In your particular case, perhaps it is better to fail in manner
B than in manner A. But, very few eCos users have the option of
failing, so nobody put in much extra effort to make things fail
in manner B rather than in manner A.  

Did that make sense?

-- 
Grant Edwards                   grante             Yow!  I'm having an
                                  at               EMOTIONAL OUTBURST!! But,
                               visi.com            uh, WHY is there a WAFFLE
                                                   in my PAJAMA POCKET??

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss