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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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 14:21:36 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!pln-w!extra.newsguy.com!lotsanews.com!newshub2.home.com!news.home.com!news.mindspring.net!not-for-mail From: "Brian Catlin" Newsgroups: comp.lang.ada Subject: Re: Ada OS Kernel features Date: Wed, 5 Sep 2001 14:10:34 -0700 Organization: Sannas Consulting Message-ID: <9n64cd$7mo$1@slb0.atl.mindspring.net> References: <9n4euv$t9m$1@slb6.atl.mindspring.net> <9n5n33$ke5$1@nntp9.atl.mindspring.net> NNTP-Posting-Host: d1.56.dc.81 X-Server-Date: 5 Sep 2001 21:10:37 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Xref: archiver1.google.com comp.lang.ada:12775 Date: 2001-09-05T21:10:37+00:00 List-Id: "Ted Dennison" wrote in message news:VLvl7.5404$4z.21201@www.newsranger.com... > 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). This is the point at which Rate Monotonic Analysis (RMA) enters the picture. The behavior of real time (and isochronous) tasks need to be well understood in order to schedule them effectively. Usually, RMA is the provence of real-time systems, but to effectively support a _few_ isochronous and real-time tasks in a general purpose operating system, we should build some tools (performance counters and such) for measuring the behavior of these tasks to help the author better optimize the code (and overall system performance). > 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. Well, I wouldn't hold Mach up as the end-all or be-all of operating system kernels; its performance is nothing to brag about. It certainly has many interesting concepts, but its overhead is too high for my taste (I haven't looked at it in several years, so it may have been cleaned up; I'll have to go check it out again). As I mentioned in a previous post, by implementing drivers as essentially applications in their own processes, the system will incur a huge amount of overhead invalidating the translation lookaside buffer and the accompanying multiple mode transitions for process context switches. -Brian