From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4948 invoked by alias); 15 Feb 2006 19:57:08 -0000 Received: (qmail 4939 invoked by uid 22791); 15 Feb 2006 19:57:07 -0000 X-Spam-Check-By: sourceware.org Received: from omr3.networksolutionsemail.com (HELO mail.networksolutionsemail.com) (205.178.146.53) by sourceware.org (qpsmtpd/0.31) with SMTP; Wed, 15 Feb 2006 19:57:05 +0000 Received: (qmail 15374 invoked from network); 15 Feb 2006 19:57:03 -0000 Received: from unknown (HELO rivatek.dnsalias.net) (67.52.40.201) by omr3.mgt.bos.netsol.com with SMTP; 15 Feb 2006 19:57:03 -0000 Received: by rivatek.dnsalias.net (Postfix, from userid 1000) id 8124854302; Wed, 15 Feb 2006 13:57:02 -0600 (CST) To: ecos-discuss@ecos.sourceware.org From: Grant Edwards In-Reply-To: References: <74C9525D67A5FF4791614FDB06593BB1028532@mail.systech.com> <87bqx9rlls.fsf@javad.com> <20060215155303.AA85C54302@rivatek.dnsalias.net> Date: Wed, 15 Feb 2006 19:57:00 -0000 Message-Id: <20060215195702.8124854302@rivatek.dnsalias.net> Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: [ECOS] Re: DSR Scheduling Problem X-SW-Source: 2006-02/txt/msg00138.txt.bz2 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