![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
I'm not sure how many of you have this problem, probably not many, but
it might help save you a lot of trouble if you do.
I've been troubleshooting this problem for weeks now, where having my Adaptec 51645 raid card in my system causes a long periodic DPC latency spike of 30000us, which is enough to cause an audio dropout. It only happens once every 10-30 minutes, so it's rather annoying to wait for to observe. Not exactly sure what it's doing there, but it's definately related to the Adaptec as I used xperf to track it down to storport.sys running a DPC related to a raid DPC subroutine.
I even ended up upgrading my rig to a Core i7 in hopes that maybe my particular Gigabyte X48 mobo was the culprit, but nope... i saw the DPC spikes again in the new system. I also hoped that moving the memory controller in the X58 might help average DPC latencies a bit, as my AMD platform had awesome DPC latencies... nope. My average latencies, which floated around 20-50us, were about the same on my old X48 as well. My AMD system floats around the 10us mark. I'm using the ASUS P6T DX for the X58.
I moved the RAID card over to my XP-based AMD system... and no DPC spikes. The XP-based system uses the SCSIport driver rather than the STORport driver, so I thought I'd go ahead and switch the driver for my Vista rig.
Sort of a bad idea. For one, if you have any boot arrays, Vista will refuse to even boot. And then the SCSIport drivers arent even signed, so you have to put your system into test mode and sign them yourself (in 64 bit vista). Then the kicker was, my huge RAID6 array suddenly came up as "Uninitialized" in the Disk Management. But the Adaptec management said my array was healthy.
Nearly having a heart attack, I reverted the driver back to STORport and rebooted. Luckily, my data partition came back alive, but the DPC spiking came back too.
I did some more research and found this utility recently released by MS:
http://www.microsoft.com/whdc/system/sysperf/intpolicy.mspx
Which allows you to change the interrupt policy for particular drivers.
I changed the Adaptec to "IrqPolicyAllCloseProcessors" from the default.
Now, instead of 30ms or 30000us spikes, I only get 2ms or 2000us spikes,
ostensibly because the DPCs were being handled much more efficiently than before.
2000us isnt long enough to cause an audio breakup.
I'm praying this issue doesn't crop up again, or I might just throw
my PC out the window. XP's interrupt scheduler never seemed to have
this many problems. In this modern day you have quadcore processors
with ridiculous amounts of processing power, but you can't even play
a MP3 smoothly because of crappy OS scheduling...
it might help save you a lot of trouble if you do.
I've been troubleshooting this problem for weeks now, where having my Adaptec 51645 raid card in my system causes a long periodic DPC latency spike of 30000us, which is enough to cause an audio dropout. It only happens once every 10-30 minutes, so it's rather annoying to wait for to observe. Not exactly sure what it's doing there, but it's definately related to the Adaptec as I used xperf to track it down to storport.sys running a DPC related to a raid DPC subroutine.
I even ended up upgrading my rig to a Core i7 in hopes that maybe my particular Gigabyte X48 mobo was the culprit, but nope... i saw the DPC spikes again in the new system. I also hoped that moving the memory controller in the X58 might help average DPC latencies a bit, as my AMD platform had awesome DPC latencies... nope. My average latencies, which floated around 20-50us, were about the same on my old X48 as well. My AMD system floats around the 10us mark. I'm using the ASUS P6T DX for the X58.
I moved the RAID card over to my XP-based AMD system... and no DPC spikes. The XP-based system uses the SCSIport driver rather than the STORport driver, so I thought I'd go ahead and switch the driver for my Vista rig.
Sort of a bad idea. For one, if you have any boot arrays, Vista will refuse to even boot. And then the SCSIport drivers arent even signed, so you have to put your system into test mode and sign them yourself (in 64 bit vista). Then the kicker was, my huge RAID6 array suddenly came up as "Uninitialized" in the Disk Management. But the Adaptec management said my array was healthy.
Nearly having a heart attack, I reverted the driver back to STORport and rebooted. Luckily, my data partition came back alive, but the DPC spiking came back too.
I did some more research and found this utility recently released by MS:
http://www.microsoft.com/whdc/system/sysperf/intpolicy.mspx
Which allows you to change the interrupt policy for particular drivers.
I changed the Adaptec to "IrqPolicyAllCloseProcessors" from the default.
Now, instead of 30ms or 30000us spikes, I only get 2ms or 2000us spikes,
ostensibly because the DPCs were being handled much more efficiently than before.
2000us isnt long enough to cause an audio breakup.
I'm praying this issue doesn't crop up again, or I might just throw
my PC out the window. XP's interrupt scheduler never seemed to have
this many problems. In this modern day you have quadcore processors
with ridiculous amounts of processing power, but you can't even play
a MP3 smoothly because of crappy OS scheduling...