I think you may not need anything extrame at all. NT/2k/XP has plenty room
for handling interrupt at 200/s. The most important thing is to estimate the
interrupt latency. In other word, what is the maximum time you have to
respond to an interrupt when the interrupt is asserted. The NT/2k/XP
typically has an average 50us response time. If it is like you said you have
to reprogram the board before next interrupt, it means you have 5ms, plenty
of time even for fat OS like NT/2k/XP.
The DOS does not work well because DOS is not multitasking OS, Network and
Disk IO have to be done in interrupt handler, for example. NT/2k/XP are
different, all most all interrupt handler (for recent hardware) does very
little in interrupt handler. Most works are done in DPC. If you use latest
PC, you are rest to be sure that IDE controller use DMA are used for CD/DVD.
If you are afraid that your interrupt handler get interrupt by higher
priority interrupt handler, you can raise IRQL in you interrupt handler than
lower it before it exits, or using asm cli/sti pair, no big deal there. You
won’t hurt anyone if you just do a few IO there.
If the task is extramely critical, such as if you don’t serve it on time,
some catastrophic thing would happen. I would not even use PC at all and
Windows at all. Since those things are subject to crash. I would use SBC
(Single Board Computer, X86 or some thing else) and RTOS. But the fact that
the older software is implemented in DOS says it isn’t that kind of
critical. Otherwise, I would use fault tolerated PC from Straus or NEC.
If I were you, I would just implement it to see how things go. If thing
works just fine, most likely, It would be all set. Otherwise, I would look
at from chipset spec to see how PCI interrupts are routed based on slot
number and pick a slot that its INTA# is not shared by other devices or is
least shared. (all most all the time they follow Intel multiprocessor spec).
I think NT gives all the PCI interrupts the same priority, I mean those
routed to IOAPIC INTR#15 or above (legacy interrupts such as IDE controller
are routed to the legacy INTR#). Microsoft people should correct me if I am
wrong so the disinformation can be stop short. It would be benificial if
Microsoft can show us how the hardware interrupt is mapped to IRQL. I
remember SoftICE manaul has some mention to it but don’t have it off-hand.
What you mentioned hack in IoConnectInterrupt will not work, if you
understand interrupt hardware such as IOAPIC and Local APIC. The interrupt
request lines (INTR) hook to IOAPIC pretty much follows Intel spec. OS maps
IOAPIC INTR (line) to certain interrupt vectors. Unless you know where the
map is stored, alter that map and reprogram IOAPIC, Local APIC, IDT to
reflect your new mapping, I doubt you can cheat OS on that.
If those lower hanging fruits is not enough, it is time to buy RT extension
of NT/2k/XP. That will definitely do for you. What RT extension does is to
only give rest of OS a chance to run if its assigned interrupts and threads
are idle. It does so by reprogram its assigned INTR to highest priority
interrupt vectors and if its interrupts are active, it mask off all the
others. Those RT extension guys spent big bugs for Microsoft source code
license.
Bi
-----Original Message-----
From: Phil Barila [mailto:xxxxx@Seagate.com]
Sent: Tuesday, November 12, 2002 10:49 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Extreme ISR Priority
“Jay Talbott” wrote in message
news:xxxxx@ntdev…
>
> I’m working on a driver for a PCI data acquisition board that will be
> used in an industrial process monitoring system. This driver will be
> limited in deployment to a couple dozen dedicated process montoring
> computers (all uniprocessor) and will not need to be WHQLable, so let’s
> not debate all the ramifications of what I’m asking here. I’m exploring
> extreme, out of the box ideas to ensure certain performance
> requirements.
>
> The external hardware connected to the data acquisition board will be
> triggering the board to generate interrupts to the PC at a rate of
> around 200 interrupts per second. The ISR needs to reconfigure the
> external hardware via the digital I/O capabilities of the data
> acqusition board prior to the next interrupt. Not getting the ISR
> processed in time prior to the next interrupt could be quite problematic
> to the system behavior. There’s not a ton of processing that has to be
> done in the ISR, but it does have to be done on time prior to the next
> interrupt.
>
> My client has commented that in the past on previous implementations of
> this system, they have run into trouble where the interrupt traffic from
> a network card installed in the system has resulted in the ISR for the
> data acquisition board not getting processed in time. Of course, that
> was also on an old system running under DOS, but I want to be sure as
> much as possible that for a Win2K/XP solution that the critical ISR will
> get processed on time.
>
> So, my question is this: How can I ensure that my ISR has higher
> priority than that of other devices in the system, such as the network
> card? Since the HAL can arrange the IRQL priorities independent of the
> traditional harwdare IRQ priorities, attempting to solve the problem by
> simply playing with which board is in which slot in the system and
> mucking with the PCI IRQ assignments in the BIOS configuration will not
> necessarily work.
>
> So here’s my thought…
>
> What if, when calling IoConnectInterrupt() for my driver, instead of
> passing the IRQL provided by PNP (that was obtained from the HAL) for
> the Irql and/or SynchronizeIrql parameters I used a higher IRQL that
> would be higher than any other installed hardware? In the truly extreme
> case, I could use IRQL_HIGH_LEVEL, but perhaps there is a less extreme
> choice that would do the job. Ignoring the performance impact on other
> things in the system (remember, I’m looking for an extreme solution),
> would this work as a solution? Or would this hopelessly screw up the
> system?
>
> Note that there isn’t all that much that needs to get done in my ISR, so
> it’s not like I’m going to be hanging out there at an extreme IRQL for
> extended periods of time. I just need to get the job done ASAP.
>
> Peter & Tony’s NT4 driver book mentions the possibility of an NT driver
> temporarily raising it’s IRQL to IRQL_HIGH_LEVEL, so I’m thinking I’m
> not too far off base with this idea.
This will prevent anyone from interrupting you while you are processing your
ISR, but it won’t do anything to get your ISR to interrupt the ATAPI
driver’s ISR while servicing a 64KB PIO read from a CDROM. (Not that I
think that’s likely in your scenario, I just wanted to point out a concrete
example of an ISR that is truly a pig of obnoxous nature.) You have to
ensure that your ISR gets to interrupt any other hardware’s ISR. For that
you have to elevate your priority level when you connect your interrupt, as
you discussed above. However, I’ve never tried anything like that, so I
don’t know if the means you proposed will actually work.
> These systems will be running plain vanilla Win2K or XP installations on
> more-or-less plain vanilla PCs.
OK, here is where you will probably run into corner cases that will kill
you once in a blue moon. If you need a real-time system, where RT is
defined as deterministic ISR latencies, among other things, you’ll need to
use an RTOS. There are real-time extensions to Windows that can probably
make it good enough. At the very least, you will probably need to limit or
even specify any hardware installed to minimize the probability of piggish
ISRs.
You said this is process monitoring equipment, so it’s mission-critical, to
some degree or other. Depending on the process, this could be life-safety
equipment, so throwing an arbitrary white box with an untuned OS on it into
that usage could be a recipe for disaster. It might be appropriate to at
least revisit the hardware requirements and ensure that you really don’t
need anything more robust.
Phil
–
Philip D. Barila
Seagate Technology, LLC
(720) 684-1842
—
You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%
