From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,TO_NO_BRKTS_FROM_MSSP autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6394e5e171f847d1 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-09-05 13:18:15 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!feed.textport.net!newsranger.com!www.newsranger.com!not-for-mail Newsgroups: comp.lang.ada From: Ted Dennison References: <9n4euv$t9m$1@slb6.atl.mindspring.net> <9n5n33$ke5$1@nntp9.atl.mindspring.net> Subject: Re: Ada OS Kernel features Message-ID: X-Abuse-Info: When contacting newsranger.com regarding abuse please X-Abuse-Info: forward the entire news article including headers or X-Abuse-Info: else we will not be able to process your request X-Complaints-To: abuse@newsranger.com NNTP-Posting-Date: Wed, 05 Sep 2001 16:17:57 EDT Organization: http://www.newsranger.com Date: Wed, 05 Sep 2001 20:17:57 GMT Xref: archiver1.google.com comp.lang.ada:12771 Date: 2001-09-05T20:17:57+00:00 List-Id: In article <9n5n33$ke5$1@nntp9.atl.mindspring.net>, Brian Catlin says... > >An isochronously scheduled task means that the task will get a fixed amount of >CPU time over time (think of it as getting a fixed percentage of the CPU over >time). Supporting isochronous tasks is a requirement if you want to be able to >handle streaming multimedia, such as audio or video. A simple way to implement Ahhh. That explains it. The multimedia folks do seem to like that term. They used it in pretty much the same sense in the FireWire spec (reserving a % of the bus bandwidth). However, I don't see anything in there that really speaks about jitter. Perhaps jitter reduction (making sure the task starts regularly at the exact same time every cycle) is just an implementation detail they don't like to talk about explicitly? The only easy way I've found to prevent jitter is to schedule a task to be the first one that runs after the clock tick. Clearly the amount of tasks one can use this solution on is limited by the product of your clock period and the task frequency (eg: 240Hz clock w/ 60Hz threads gives you at most 4 possible jitter-free tasks). However, I heartily agree that the scheduling algorithm would need to be different for RT and non-RT tasks. >Yes, it makes them more difficult to debug, but placing the drivers in the >kernel has several benefits: >1. Processing an I/O request requires access to privileged system routines and .. >2. Putting drivers in user-mode means increasing the number of transitions .. >3. A driver will need access to the requesting process' address space, but if .. Interesting. But I'm pretty sure that Mach puts *all* device drivers into user space, as well as large parts of the kernel. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com