50ms latency normal operation? I could be wrong here, but I am skeptical. That would cause things like game frame rates to stutter, the mouse pointer not to move smoothly, audio to break up, etc. And it would put a damper on the idea of fatal1ty usb ports. It’s even hard for me to understand how latency has gotten worse over the decades since everything is so much faster than 1980 hardware. I’d like to see some measured latency to look at some factual metrics about real world latency best/worst case scenarios. It would be really good to understand that.
Well, it depends on what we understand by “interrupt latency”, i.e. whether we speak about checking/ACKing interrupts or actually processing them, i.e. if we speak about ISR or DPC latency. The former is normally not going to be that high unless we speak about some "emergency"situations like SMI or CPU overheating, simply because you are not allowed to do anything, apart from checking the device and queueing a DPC, in ISRs. Therefore, even if ISR is blocked by some higher-priority interrupt(s), the situation is going to get resolved pretty shortly.
When it comes to DPC, the situation is totally different, because you are, first,allowed to re-queueu
a DPC from aDPC routine, and, second, to enqueue a DPC to the front of the queue.
Consider the following scenario. Say, ISR X that queues a DPC A gets interrupted by ISR Y that queues a DPC B. Both A and B are of high priority, i.e. get enqueued to the head of DPC queueu. Which of them is going to run first? It depends on whether ISR X gets interrupted before or after it has queued its DPC - in the former case DPC A will run first, and in the latter one it is going to be DPC B.
Now let’s say DPC B in some cases re-queues itself as a high-priority DPC (i.e. to the head of the queue) before returning, and does so multiple times until some condition is met. In practical terms, this is exactly the same thing as a tight polling while() loop, but once DPC routine actually returns before getting invoked again its driver has all chances to pass 100_us certification requirement, because it ostensibly “plays by the rules”.
What is the maximum latency of DPC A under these circumstances???
Anton Bassov
Well, we are all familiar with mouse pointers freezing and no keyboard echo,
sometimes for several seconds, on a typical PC. Audio is only going to work
if you have decent size buffers, I think 50ms hardware buffers would be
considered dangerously low, and 8192 samples is not uncommon. I recall
reading that Microsoft’s own definition of their goal for professional audio
quality as “almost no glitches”.
----- Original Message -----
From: xxxxx@gmail.com
To: Windows System Software Devs Interest List
Sent: Wednesday, April 06, 2016 6:52 AM
Subject: RE:[ntdev] RealTime Serial Communication in Windows
50ms latency normal operation? I could be wrong here, but I am skeptical.
That would cause things like game frame rates to stutter, the mouse pointer
not to move smoothly, audio to break up, etc. And it would put a damper on
the idea of fatal1ty usb ports. It’s even hard for me to understand how
latency has gotten worse over the decades since everything is so much faster
than 1980 hardware. I’d like to see some measured latency to look at some
factual metrics about real world latency best/worst case scenarios. It would
be really good to understand that.
NTDEV is sponsored by OSR
Visit the list online at:
http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</http:></http:>
>50ms latency normal operation? I could be wrong here, but I am skeptical.
I think Jan said it’s “the timeout implemented in the root complex” like
when “the device doesn’t respond to the config read at all (like the
firmware crashed)”.
Latencies of 50ms (at elevated IRQL) are not normal or common even on the
worst behaving systems.
//Daniel
I’d settle to hear anyone provide an explanation of what their ISR is doing for 100 microseconds–that’s an absolute eternity. And with bus mastering and SGLs there should be very little processing compared to the days when double buffering and PIO were performed in the ISR.
> I’d settle to hear anyone provide an explanation of what their ISR is doing for
100 microseconds–that’s an absolute eternity.
As Jan Bottorff explained, delays can be caused by hardware (like access to a PCI config space register that contains the interrupt request bit). Normally this is fast but… things happen. The device can be virtualized, simulated… And Mr. Bassov reminded about SMIs. Other devices can interfere too (I have learned this in a hard way).
Very much depends on the hardware platform, under any OS. Linux or QNX or Windows CE.
On the other hand, often a small simple microcontroller is enough for the real time part of the system. These little things are simple, they therefore have less gotchas. It’s easy to ensure that they do only what is needed, and nothing else. They may be even cheaper than writing and testing a non-trivial driver 
– pa
Except when you don’t use bus master DMA. Or your Bus Master doesn’t support DMA chaining.
We have whole classes of buses that are slow and use little power these days, oOf course, the ISRs for these devices typically run at IRQL PASSIVE_LEVEL…
But, my point it, the PC world is not nearly as homogenous as youseem to think. There a lot of weird hardware out there. It’s not all MSI-X and fast writes to memory and let’s stay on this NUMA core to maximize our cache locality. Shit… System DMA support just got reinvigorated in Wimdows 8. You’d probably be surprised if you knew some of the crazy shit going on in your phone,
Peter
OSR
@OSRDrivers
>I’d settle to hear anyone provide an explanation of what their ISR is doing for 100 microseconds–that’s an absolute eternity.
It’s not an ISR that’s a problem. A timer routine will run in a DPC. Drivers, in some conditions, may have to spend a lot of time in DPC. For example, an L2 driver of a high throughput network card may hit TCPIP.SYS bottleneck (some global table spinlock), and cause the spinlock churn, and then its all RSS DPCs will try to get through that spinlock, which, for some reason, was not implemented as a read/write lock. And then you get DPC timeout. Real story.