-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul G. Allen wrote: > On Fri, 2007-06-15 at 20:32 -0700, Richard Reynolds wrote: >>>> That sure sounds a LOT like preemptive multitasking to me. >>> The ISR should have preempted whatever else was happening, but it would >>> not. >> I donno, the fact you wanted the ISR to be triggered right away and it >> was not, does not sound like a valid argument that the OS is not doing >> preemptive multitasking. > Hmmm, no other interrupts are active, no other higher priority tasks > being executed, but yet the one interrupt that gets triggered does not > get serviced. Sounds like something is not being preempted to me.
No, it means something is not getting scheduled when you want it to be scheduled. I have no idea why it didn't happen in your case, but this problem happens all the time with Linux (hence all the low-latency patches for people doing sound work), and indeed is actually much worse than NT unless you have low latency patches applied. Despite this, Linux is considered a preemptively scheduled OS. Really, all that preemptive multi-tasking implies is that the currently running process may be interrupted by the kernel without the task explicitly requesting it (typically this is done with a timer-based interrupt). It does *not* imply that a higher priority task will get scheduled in some reasonable amount of time. That is where terms like "real time" and "low latency" come in to play. Preemptive multi-tasking isn't so much about when your task gets to run, but rather when your task *doesn't* get to run. The key consequence of preemptive multi-tasking is that you can't assume that it will run without interruption, which is frighteningly similar to your problem. >> In that it worked sometimes but not others sounds like >> you just didnt get the priority you wanted. The fact M$ could not help you >> fix it also does not sound like a valid arguement either. It sounds like an >> argument for a zillion other things, including against the use of windows. > > How many people here have looked at a PC with NT running using a logic > analyzer for weeks on end? (I have). How many, while they did this, were > working with a team of application and OS engineers during the process? > (I was) How many, while doing both, were M$ development partners and had > daily contact with M$ engineers (we did). Well, I never used a logic analyzer on the NT kernel, but I think have the rest of the bases covered. In a past life I worked on an NT file system driver, and in a previous life before that I worked at a company where we wrote all kinds of NT drivers for embedded devices. Most of the latter required a very responsive kernel. We never had much problems with NT in terms of responsiveness. Indeed, several flavours of Unix (not the ones designed for embedded systems, they were all great) were much worse. NT's kernel, IO model and driver model in general are insanely complex, which makes it difficult to untangle problems like yours (not having source makes it even worse, although debug symbols help a lot), but noone gave NT's kernel points for elegance and simplicity. > Now tell me how NT is a true preemptive OS? Because it allocates CPU time on a time sliced basis and the kernel is able to interrupt user space at its convenience. Heck, NT even allows kernel level threads to be preemptively interrupted, which a number of preemptive multitasking OS's don't support like (pre-Solaris SunOS). > I'm listening and would like > to know if the data we found was wrong (I honestly would). Also tell me > how a high priority interrupt like the vertical blanking interrupt can > take so long to service in this preemptive OS that the vertical blanking > interval (which is long in computer terms) is nearly complete by the > time it's serviced? Well, a few things come to mind immediately. You are distinguishing between NT and W2K, so I'm wondering if perhaps you were working with one of NT 3.1, 3.5, or 3.51. If that is the case, part of your problem might have been related to NT's GUI subsystem operating primarily in user space. This was changed in NT 4.0 in order to improve performance, but prior to that, most GUI work had the extra overhead and latency of having to wait to get up in to userspace and get scheduled. The *usual* thing I ran in to when we had scheduling problems was that the service routine for the interrupt, the ISR, was not bound to a sufficiently high priority request level (IRQL). This was often necessary, because as you get up higher and higher in the IRQL's, there are fewer and fewer kernel services available to you (they literally run at a lower priority than the routine, so you can't use them). Typically what NT drivers do to deal with this is something like a client/server model, where a high priority ISR queues up requests to a lower priority routine, which then invokes the kernel services at a later time. While this works (and isn't entirely different from how Linux handles interrupts), it does produce a not insignificant amount of latency overhead (which is why filesystem drivers get to use the special "fast path I/O" to overcome performance problems). More importantly, the lower priority task may not get to run for a while because various other miscellaneous drivers get in the way, or worse yet some low latency sleep is going on at a higher level. The other one that was special was having some other driver masking interrupts for so long that a big queue of interrupts built up before they get a chance to be properly service. That was always annoying. NT's complex scheduling and preemption rules are no doubt exactly *why* the MS engineers had a hard time figuring out how to help you. Indeed, if NT wasn't preemptively multi-tasked, the solution becomes a lot simpler, though uglier (namely: don't give up CPU time until you have received your interrupt). > BTW, I've found (though I no longer have the resources I once had) that > apparently W2K is no better at servicing interrupts than NT was. IIRC, W2K actually did get a little bit better in its context switching overhead. Not exactly breakthrough, but an improvement. XP undid the win (and then some I think). - --Chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGdtheOagjPOywMBARAs0dAJsHDyr+z12sXeusaxk6Ud0H2tazuwCfV3E2 rrLN/J0RmCe7T9a4/4e+U8w= =EjBF -----END PGP SIGNATURE----- -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
