Hi All,
I am working on a device driver for our hardware. I found the time
period from the hardware assert the INTA pin to my driver’s ISR
deasserting this pin is about 10us in the logical analyzer. But the NIC
interrupt response only takes about 100ns. My ISR only deassert the INTA
pin by write the hardware register, just one C statement. I use the
Numega DriverWorks to develop the driver including the ISR, but I don’t
think the overhead will be that large. How long should be normal? Do you
have any idea on this? Thank you!
William
William,
May be you have to look into, what is the irql level of the ISR.
Also, wrapper around ISR may also lead to extra dealy. Numega people might help you in this regard.
Bye…
Al
William Zhang wrote: Hi All,
I am working on a device driver for our hardware. I found the time
period from the hardware assert the INTA pin to my driver’s ISR
deasserting this pin is about 10us in the logical analyzer. But the NIC
interrupt response only takes about 100ns. My ISR only deassert the INTA
pin by write the hardware register, just one C statement. I use the
Numega DriverWorks to develop the driver including the ISR, but I don’t
think the overhead will be that large. How long should be normal? Do you
have any idea on this? Thank you!
William
—
You are currently subscribed to ntdev as: xxxxx@yahoo.com
To unsubscribe send a blank email to %%email.unsub%%
---------------------------------
Do You Yahoo!?
Yahoo! Shopping - Mother’s Day is May 12th!
Maybe the problem is in the hardware? Maybe this is how long it takes
for your hardware to deassert the pin after you write to the register?
— William Zhang wrote:
> Hi All,
>
> I am working on a device driver for our hardware. I found the time
> period from the hardware assert the INTA pin to my driver’s ISR
> deasserting this pin is about 10us in the logical analyzer. But the NIC
> interrupt response only takes about 100ns. My ISR only deassert the INTA
> pin by write the hardware register, just one C statement. I use the
> Numega DriverWorks to develop the driver including the ISR, but I don’t
> think the overhead will be that large. How long should be normal? Do you
> have any idea on this? Thank you!
>
> William
>
> —
> You are currently subscribed to ntdev as: xxxxx@yahoo.com
> To unsubscribe send a blank email to %%email.unsub%%
__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Mother’s Day is May 12th!
http://shopping.yahoo.com
> I am working on a device driver for our hardware. I found the time
period from the hardware assert the INTA pin to my driver’s ISR
deasserting this pin is about 10us in the logical analyzer. But the NIC
interrupt response only takes about 100ns. My ISR only deassert the INTA
pin by write the hardware register, just one C statement. I use the
Numega DriverWorks to develop the driver including the ISR, but I don’t
think the overhead will be that large. How long should be normal? Do you
have any idea on this? Thank you!
MANY things might cause this.
You are aware that on a PCI device YOUR driver may be down a chain of ISR’s
at the same level. You have no control over how long the ISR’s ahead of you
in the chain takes to see if the interrupt belongs to them. Many ACPI
systems will chain ALL the PCI devices on the same interrupt level. There
was a really interesting message thread about WHY this was so some months
ago on this list.
Offhand, 10 microsec to get your ISR to respond sounds not unusual for a
good case. In a not so good case, expect longer. The REALLY ugly case is
when you have a video card or some other device that does ugly things with
PCI retries, and can cause interrupt latency of like 10 milliseconds. I’ve
seen hardware devices where the ISR needed to respond within a few
microseconds, and basically told the client they had better redesign their
hardware if they wanted it to reliably work on Windows.
There was a big white paper on ISR latencies done by Intel a few years ago.
I believe the URL was posted in the list back then. You might also do some
searching on the Intel sight. The data may not have been updated for W2K
and WXP.
> good case. In a not so good case, expect longer. The REALLY ugly case is
when you have a video card or some other device that does ugly things with
PCI retries, and can cause interrupt latency of like 10 milliseconds. I’ve
seen hardware devices where the ISR needed to respond within a few
microseconds, and basically told the client they had better redesign their
hardware if they wanted it to reliably work on Windows.
Why Windows? Windows does not do PCI retries.
This hardware will fail on any OS if the video card is one of those misbehaving ones.
Max
It certainly depends on the hardware platform (clock rate, bus type, PCI bridges), and
also on whether you are getting cache hits.
On a 2Hz P4, 10 us is 20,000 CPU clocks! It would be pretty bad if this was “typical”.
The main cost items are:
- The hardware interrupt latency. Bridges do try to delay the interrupt until any previously
queued data reaches memory. If your hardware DMAed a bunch of data into memory
then generated an interrupt, a bridge might add a significant delay on the interrupt.
- PCI register reads. If you were sharing interrupts with another driver, and that driver
read some PCI registers to determine if there was an interrupt, this could take a while
(but getting to 10 us is hard just on a couple PCI reads), stalling the CPU.
- Cache Misses. If you are trying to have a clean sample, and are measuring the first
interrupt from this device, you could probably get a substantial number of cache misses.
These can be 100s of clocks each at high clock rates. See what happens if you
generate a second interrupt almost immediately after the first is ACKed.
- Incorrect use of uncached memory in the driver. I’ve seen drivers that use uncached
memory to hold their own data structures, etc.
-DH
“William Zhang” wrote in message news:xxxxx@ntdev…
>
> Hi All,
>
> I am working on a device driver for our hardware. I found the time
> period from the hardware assert the INTA pin to my driver’s ISR
> deasserting this pin is about 10us in the logical analyzer. But the NIC
> interrupt response only takes about 100ns. My ISR only deassert the INTA
> pin by write the hardware register, just one C statement. I use the
> Numega DriverWorks to develop the driver including the ISR, but I don’t
> think the overhead will be that large. How long should be normal? Do you
> have any idea on this? Thank you!
>
> William
>
>
> > good case. In a not so good case, expect longer. The REALLY ugly case is
> when you have a video card or some other device that does ugly things with
> PCI retries, and can cause interrupt latency of like 10 milliseconds. I’ve
> seen hardware devices where the ISR needed to respond within a few
> microseconds, and basically told the client they had better redesign their
> hardware if they wanted it to reliably work on Windows.
Why Windows? Windows does not do PCI retries.
This hardware will fail on any OS if the video card is one of those
misbehaving ones.
Well no. The issue is that to get the very best benchmark numbers on things
like the PC Mag tests, hardware vendors will leave out the test of a FIFO
level in the driver before writing to it. So instead of a driver write to
the graphics accelerator command address being a test for space in a
FIFO followed by the command write it’s just a command write, with the
hardware stalling the PCI write with retries until space is available in
the FIFO. The CPU does not respond to interrupts while this is happening.
Having the top spot on the magazine benchmarks can make a large difference
in sales (millions of dollars). A common case for this showing up is to
scroll a large screen at deep color depth. To scroll a 1280x1024x32 screen,
takes around 8 MBytes of video memory bandwidth. This means it takes 10
milliseconds if you have 800 MBytes/sec memory (i.e. 100 Mhz 64-bit wide
SDRAM). If you just pour scroll commands into the FIFO, eventually you will
fill the FIFO, causing the PCI retry latency problem.
Fortunately, memory bandwidth is getting better, although screen
resolutions are also climbing. The REAL question is the ethics of the
device driver writer (actually their management). The Windows graphics card
market was (is?) VERY competitive, and MAJOR vendors have pulled this trick.
Fortunately, the smart vendors have realized they are pissing off customers
by putting unfriendly drivers in their systems, and many, probably most,
video cards have two modes of operation. One for the benchmarks and one
that makes the card a friendly, albeit slower, player in the box. There was
an article on this somewhere a couple of years back, but I can’t find it
now. Not sure which way most of them default though either.
–
Bill McKenzie
“Jan Bottorff” wrote in message news:xxxxx@ntdev…
>
>
> > > good case. In a not so good case, expect longer. The REALLY ugly case
is
> > > when you have a video card or some other device that does ugly things
with
> > > PCI retries, and can cause interrupt latency of like 10 milliseconds.
I’ve
> > > seen hardware devices where the ISR needed to respond within a few
> > > microseconds, and basically told the client they had better redesign
their
> > > hardware if they wanted it to reliably work on Windows.
> >
> >Why Windows? Windows does not do PCI retries.
> >This hardware will fail on any OS if the video card is one of those
> >misbehaving ones.
>
> Well no. The issue is that to get the very best benchmark numbers on
things
> like the PC Mag tests, hardware vendors will leave out the test of a FIFO
> level in the driver before writing to it. So instead of a driver write to
> the graphics accelerator command address being a test for space in a
> FIFO followed by the command write it’s just a command write, with the
> hardware stalling the PCI write with retries until space is available in
> the FIFO. The CPU does not respond to interrupts while this is happening.
> Having the top spot on the magazine benchmarks can make a large difference
> in sales (millions of dollars). A common case for this showing up is to
> scroll a large screen at deep color depth. To scroll a 1280x1024x32
screen,
> takes around 8 MBytes of video memory bandwidth. This means it takes 10
> milliseconds if you have 800 MBytes/sec memory (i.e. 100 Mhz 64-bit wide
> SDRAM). If you just pour scroll commands into the FIFO, eventually you
will
> fill the FIFO, causing the PCI retry latency problem.
>
> Fortunately, memory bandwidth is getting better, although screen
> resolutions are also climbing. The REAL question is the ethics of the
> device driver writer (actually their management). The Windows graphics
card
> market was (is?) VERY competitive, and MAJOR vendors have pulled this
trick.
>
> - Jan
>
>
>