Re: [ECOS] Re: DSR Scheduling Problem

[Brett Delmage <brett at twobikes dot ottawa dot on dot ca>]

On Wed, 15 Feb 2006, Sergei Organov wrote:

> Brett Delmage <brett@twobikes.ottawa.on.ca> writes:
> 
> > On Mon, 13 Feb 2006, Sergei Organov wrote:
> >
> > <nice analysis deleted>
> >
> >> Overall, the above analysis suggests LIFO is never better than FIFO and
> >> it could be much worse than FIFO.
> >> 
> >> Isn't it time to finally get rid of LIFO wait queues in eCos? Any
> >> objections?
> >
> > Isn't eCos about choice?
> 
> Well, unfortunately choice doesn't come for free. More testing, more
> opportunities for bugs, more confusion, etc. I believe useless choices
> are evil.
> 
> > Make this configurable option and allow users to try both. :-)
> 
> Which of the options do you suggest to be the default?

I have to agree with Grant that the current implementation should continue 
to be the default, because it is the expected behavior.

> How do you explain users the criteria to choose one algorithm or 
> another?

Again, I agree with Grant about that the user should be provided with the 
information (pros, cons) about each and can make a choice, and ideally 
benchmark their own application. As we have already seen, depending on 
application implementation, the advantages and disadvantages of each can 
change completely or not matter at all.

> How will user compare the choices in his tests when most of time the 
> algorithms behave exactly the same? How do you explain why LIFO choice 
> is there in the first place if it has no advantages?

Put the mathematical model that was recently posted into the package 
documentation and let the user decide ;-)

As with other open software, a significant benefit/feature/characteristic 
of eCos is its value as an educational tool. When I first started 
learning about eCos, I really liked, for example, the *different* 
implementations of the scheduler being available, with explanations. 
Design is always about tradeoffs, especially in embedded systems. The 
different implementations of functions in eCos are really useful as 
optimizable building blocks, but they also help developers to see and 
understand tradeoffs, such as efficiency vs latency. This knowledge can 
also be applied in their application code.

For the case in point, by including two DSR algorithms, people get to 
think more about what makes a good and bad algorithm, and study the 
differences. If a "bad" algorithm (whatever that may be!) was removed, 
then that learning opportunity would be lost.

The educational value of a F/LOSS eCos is truly important and something 
to be proud of. I urge contributers (of which one day I hope to be one, 
after I get my first port working!) to remember that as they contribute.
You're not just making a great tool: you're advancing human knowledge.

Brett
embedded software developer
Ottawa, Canada


 

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