This is a continuation of another thread: "What's better: modern built-in motherboard sound chip or old sound card?"
I know NT isn't real-time, but 50ms for an IRQ to be handled sounds ludicrous. And AFAIK, data processing isn't done directly in the IRQ handler, instead some state information is saved and passed down as an IRP, and the IRQ handler itself finishes quickly. Iirc Linux does somewhat the same by having "high" and "low" parts of their IRQ handlers.
In a real-time driver, there is a high, middle, and low part.
The highest (hardware interrupt) part strictly services the hardware, and schedules the software interrupts and their service priorities (usually 0-63). It may schedule several software interrupts since different parts (I/O initialization, I/O continued service, I/O completion) may require different priorities. It will also grab the data and cache it if there are any. It's usually about 15 instructions or less. Of course, its reentrant coding.
The middle tier routines will service the data. This also must be reentrant coding, so 95% of the system calls can't be made from this level. Obviously, no C library calls can be made from this level either since the C library isn't reentrant. If necessary, this level will schedule a completion routine to be executed at the next level.
For the lowest tier (completion routines), the OS does save all processor registers automatically so there's high context-switch overhead entering this tier. The good news is that your code does not have to be reentrant, so all the system calls are available to you as well as the C library.
It's interesting to note, but the service rates of each tier are highest, 3000 interrupt/sec; middle 300 interrupts/sec; and lowest 30 interrupts/sec. Note that the maximun service rate of the lowest tier is the same in both the real-time OS as well as the conventional OS. That's because both have the same context-switch overhead at this level because both are saving/restoring all the registers.
For (real-time) rate monotonic scheduling, we want each completion routine to have its own unique priority so there's deterministic (ordered) execution. That's why real-time OSes (RTOSes) have so many priorities.
Windows is sluggish at handling interrupts. I've had problems with National Instruments multifunction I/O cards giving me 50mS service rates and National says there's nothing they can do about it. I admit these laboratory machines have a lot of I/O going on in them though. That's why National offers a 486 processor with a Far-Lap OS (RTOS) for real-time control needs on Windows. Edit
: I just realized this was a driver-service problem with several Windows 95 machines. The "native" Windows 2000 driver model should perform much better.
Hadn't heard about real-time NT, are you sure you're not thinking of NT embedded?
We are definitely talking about the same product. In 2000, it was called Real-time Windows NT, but now Microsoft is calling it Windows Embedded. I just visited their website http://msdn.microsof...mbedded/default.aspx
It's a scalable version of Windows such that you can scale its memory foot print, which is important. I think it's still over 500K though when really scaled down, but my information is old on this spec (1997).
Just because something is embedded doesn't mean it has to be hard real-time.
I agree. It is possible to do hard real-time in software, but I honestly believe hard real-time tasks are better done in hardware today because design tools for FPGAs are so easy to use now. In addition, some SoC chips (Excalibur) incorporate both a processor as well as an FPGA all on the same chip, so doing both firmware and a gate array design does not
increase chip count.
Iirc there's also just one scheduler in the whole of NT, used for both usermode and kernelmode stuff - although there's a distinction between usermode and kernelmode threads. The "scheduler" also isn't a separate modular part, it's interweaved in most of the NT kernel because of it's particular design.
If that's true, then that's really bad
design. Please tell me that's not true. In the application layer, you have two things to deal with you don't have in the driver layer. One is protection switches (with the Memory Management Unit, MMU), and the other is semaphore testing and processing--which is really messy and big overhead--in a scheduler. Some would also include resource awareness (what resources are tied up by awaiting processes), but I'm counting that case under semaphore management here.
In contrast, the driver scheduler has none of this overhead. That makes it really lean and mean, which is something we really want in all OSes. The typical OS implementation (and I think Linux works this way), is the let the high overhead application layer scheduler run as a driver-level task in the lowest priority, 63. All other driver-level tasks run between priorities 0-62 such that when they complete, then the high-overhead scheduler runs.
As for priority levels, there's 32 of them, with one being REALTIME. While that priority isn't strictly "realtime" by computer science terms,...
I follow what you're saying, but I wouldn't look at it that way. All first tier (hardware interrupt) driver tasks must all complete first. Afterwards, all second tier driver tasks must compete and there's no special priorities for these. After that, then priories 0-31 for the main scheduler get attention where priority 0 is the real-time completion routine (which I "think" is swapable like anything else in the application layer, but maybe there's an exception here). The point is Windows places it's completion routines in protected mode, which means more context-switch overhead (with the MMU) but they would be easier to write and debug than if they were in the driver layer.
Unlike Windows, most OSes require you to reload the entire OS if you enlarge the driver for any reason. This makes developing in the driver layer inconvenient. Although placing the completion routine in the application layer means more context-switch overhead (MMU register switches for protected mode), it is handier for development.
Most RTOS application designs don't even have MMU hardware, so doing completion routines in the third tier of the driver layer makes sense since the application layer isn't protected anyway.