[ECOS] Re: DSR Scheduling Problem

[Grant Edwards <grante at visi dot com>]

In gmane.os.ecos.general, you wrote:

>> The existing one, of course.  Always default to existing behavior when
>> adding new options.
>
> So the result in this given case is that the worst option is
> the default one :( I don't in fact care much about theory, --
> but the result does matter, IMHO. Backward compatibility is
> very valuable goal, but keeping it is not *always* the right
> choice, especially provided that an application that could
> break relies on undocumented implementation detail and thus is
> already somewhat broken.

I hate to be overly pragmatic, but that's often just the way
things are.

> We just need to come to a reasonable decision after weighting
> all pros and cons, -- that's why I have posted this in the
> first place.

As I've said, I think keeping the old DSR scheduler and adding
an optional new one is the reasonable choice.  For the vast
majority of applications it just doesn't matter, and leaving
the current one as the default has the lowest risk of breaking
existing applications.   I guess I just don't think there are
that many applications where FIFO has a measureable advantage
to take the risk.

>>> How do you explain users the criteria to choose one algorithm
>>> or another?
>>
>> You don't.  Just explain the differences between the two
>> algorithms.  It's up to the user to determine the criteria on
>> which he's making his choice.
>
> So are we going to give user a hint? I mean something along the lines:
>
> "LIFO policy may introduce 2 times higher DSR latencies at some rare
> conditions than FIFO and ARRAY, but it's there and is the default for
> backward compatibility. Please consider to use either FIFO or ARRAY for
> new projects."

That's fine with me.

>>> How will user compare the choices in his tests when most of time the
>>> algorithms behave exactly the same?
>>
>> That's up to the user.
>
> Seems like putting on the user the responsibilities he can't cope with
>:(

How are we supposed to run/evaluate tests of the user's
application?

>>> How do you explain why LIFO choice is there in the first place
>>> if it has no advantages?
>>
>> It's already been explained:  LIFO is fast and dirt-simple.
>
> ... with the worst real-time properties of all the available options :(
>
> BTW, FIFO is fast and dirt-simple as well.

>> The most important excuse is not changing things for people who
>> have working systems.
>
> Strictly speaking, not to break working system means not to change
> anything, that in turn means not to switch to a new eCos version.

That's true.  A lot of work is involved in switching to a new
eCos version.  Changing the DSR scheduling algorithm on top of
that just adds a bit more risk.

> [What in fact bothers me is why don't you care, -- do you in
> fact still have feeling that LIFO could be better in some
> cases? I'd be thankful if you share it with me if you have.]

I have the feeling that for everything I've done, LIFO works
just as well as FIFO would.  I'm convinced that changing to a
new DSR scheduling scheme will be of no benefit to my
applications and represents a small (but non-zero) risk.

For example: We recently switched from the NetBSD TCP stack to
the FreeBSD stack because the latter is what's recommended and
what is being actively maintained.  There was a fringe benefit
of somewhat lower CPU load and higher TCP/IP throughput.

However, it broke our application in certain scenarios.  There
was a bug in the FreeBSD stack.  It was fixed 6 years ago in
the NetBSD stack, but never got fixed in the FreeBSD stack.  We
now have a rather frustrated and irate customer and have spent
quite a few hours duplicating the problem and tracking down the
bug in the FreeBSD stack.

Change is risk.

>>> The only one I see is backward compatibility, but due to the fact
>>> that eCos never specified exact order of DSRs it shouldn't matter.
>>
>> Lots of things that shouldn't matter do.
>
> Yes, indeed.

> I don't believe you really think that *every* change to eCos sources
> should be put under yet another option as some "working" system
> somewhere may break, right?

I think that in general, new features or fundamental changes to
existing features should be optional if possible.  Sometimes
that's simply not practical, but I think it is in this case.

-- 
Grant Edwards                   grante             Yow!  My ELBOW is a remote
                                  at               FRENCH OUTPOST!!
                               visi.com            

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