Hi,
I have seen lot of forums all over the net where guys abuse each other as there is no tomorrow. I applaud both cranky and BLASTO for stepping back from the heat of the arguments and handling this as two mature men.:clapping:
To better explain the scenario for more techy members,
Cranky was looking at 'out of the box' permance in trems of DPC (Deferred Procedure Call) handling. 'Lantency', while is a generic term used to denote any 'delay', apparently has been used in the music/video making world to denote only 'DPC Latency' which Iam not aware of. Or in other words, 'Latency' would not inherently mean 'DPC latency' to 'me' as I deal with a lot of other latencies too.
Now, as for what DPC latency itself is,
The Sytesm/Kernel drivers work at a higher prority than the user processes. To make this happen, the kernel dll are made capable of 'deferring' the procedure call made by the low priority user processes for a short time typically a max of100 uS. Usually this max time is never reached. The kernel dlls return within 20-50uS.
When seen from the user process's (here a audio/video application) perspective, it CAN get its procedure call deferred (delayed) by some amount of time due to kernel dlls deferring its procedure calls. If this delay is high, It might lead to skipping or blank spots in the audio/video output. This delay is call 'DPC latency' and a A/V application can run seamlessly on a system with <250uS.
As you can see, For the whole process to work, each individual kernel dlls should not defer the procedure calls by user processes >100uS. Only drivers which satisfy this criteria are 'certified'.
It so happens that the vendors does not bring out drivers during an OS launch as quick as we might expect. This is the problem we face during all OS releases. The end customers choose to use the driver they are aware of from an earlier version of the OS which might cause various performance issues including DPC latency (and a whole lot of other issues as well). This is termed as a performance issue of the OS itself.
While my machine was capable of producing <125uS DPC latency (attached earlier) for every 1000uS measured, Cranky's system could only archieve even <500uS with the same tool. There is definitely one or more faulty drivers which are responsible for this.
My test in 5 machines around me (which are not as high end as cranky's) yielded me results ranging from 100uS to 200uS (laptop). So an inherent OS issue is ruled out.
I and cranky are in the process of narrowing down on the faulty driver in his system. Will get back with he results. IMO, His machine is capable of attaiing ~120uS with full AERO and <100uS without AERO from the comparison I made with a similar system.
