IRQ CPU Affinity Setting

[manisandher]

Hey Nick,

Yeah, I'd already figured this out - I'm on scheme 3. But thanks for the reminder.

I've been viewing CPU activity during playback, and it does seem that ordinarily nothing much other than XX gets appointed to CPU1. However, programs like 'Latency Checker' seem to get appointed there also, when running.

I was wondering whether it would be worth creating 8 cores with hyperthreading and 'hogging' a whole one for XX, a whole one for the device driver, etc...

Mani.

[Nick]

As promised this is the full list of IntFilters that I am running on my thin Vista Build. I have added more elements to the CPU 0 list after today’s power cut in my village and the sound has improved by a large step again !

As you will see a great deal of stuff is on CPU0 and has to "get by" on just a 3GHz processor  (on my machine) poor processes

If you want to try the settings add them say 10 at a time and reboot so that you can fault find if they do not work for you machine. They are not a random selection though so they should be reasonably close straight off I hope.

Nick.

The information is attached in both Word and Excel formats

[Nick]

Mani,

For the amount of effort involved it might be fun to try Hyerthreading. I have not had much experience but I used it a few years ago on a single core CPU I had. It worked very well and made a difference to music back then. Reading the IntFilter doc the system seems to support Hyperthreaded CPUs

You could have system stuff on one or two CPUs then XXHighEnd, and your playback drivers on separate CPUs with the rest of them. Not sure how it would sound but its nice to find a use for EIGHT! cpus 

Nick.

[manisandher]

As promised this is the full list of IntFilters that I am running on my thin Vista Build.

Hey Nick, thanks so mucj for this - I really appreciate it. Will try this later and let you know how it sounds.

Cheers,
Mani.

[Josef]

>If you want to try the settings add them say 10 at a time and reboot so that you can fault find if they do not work for you machine.

Nick, isn't this a bit dangerous? According to http://www.microsoft.com/whdc/system/sysperf/intpolicy.mspx :
"generally you should not use IntPolicy on any device sharing interrupts with another device"

Like you, I also have a USB-to-SPDIF and 'USB Host controller' apparently sits on IRQ 20. But that IRQ is shared by 2 other USB Controllers, one of which is 2nd USB port with mouse and external HD on it (and via External Hub to make matters more complicated...)
Is it wise to change affinity then? (I'd rather not risk if there is a chance of problems)

Also, in your Word Doc you suggest to set affinity for sound card i.e. driver: But the sound card itself does not have any IRQ assigned and according to above link:
"Even though all the computer devices appear in the Devices list, we recommend that you use IntPolicy only on devices that have interrupt resources"

They don't say why they recommend it, but it makes me having second thoughts.....

What is the situation in your system: Does your USB controller share IRQ with other devices? Have you then set affinity for _all_ those devices?

[manisandher]

Will try this later and let you know how it sounds.

How does it sound? Well, very nice indeed! I've just had my brother over and through headphones (my AKG-1000s are the most revealing I've ever heard), he couldn't tell the difference between vinyl and a 24/192 recording played back on XX. And I'm not sure I can anymore either.

Thanks for all the effort Nick - your tweaks have been superb.

Oh and for anyone who is tempted to try this, it should be totally fine and straight forward - my earlier issues were my own doing and not the SW's. But it is quite laborious setting all the affinities...

Mani.

[Nick]

>If you want to try the settings add them say 10 at a time and reboot so that you can fault find if they do not work for you machine.
Nick, isn't this a bit dangerous? According to http://www.microsoft.com/whdc/system/sysperf/intpolicy.mspx :
"generally you should not use IntPolicy on any device sharing interrupts with another device"

Like you, I also have a USB-to-SPDIF and 'USB Host controller' apparently sits on IRQ 20. But that IRQ is shared by 2 other USB Controllers, one of which is 2nd USB port with mouse and external HD on it (and via External Hub to make matters more complicated...)
Is it wise to change affinity then? (I'd rather not risk if there is a chance of problems)

Also, in your Word Doc you suggest to set affinity for sound card i.e. driver: But the sound card itself does not have any IRQ assigned and according to above link:
"Even though all the computer devices appear in the Devices list, we recommend that you use IntPolicy only on devices that have interrupt resources"

They don't say why they recommend it, but it makes me having second thoughts.....

What is the situation in your system: Does your USB controller share IRQ with other devices? Have you then set affinity for _all_ those devices?

Josef,
I selected mother board based USB deliberately in order find a port with its own IRQ but I have used PCI based USB cards which had shared IRQs in the past. Try to find a port with its own IRQ if you can but sometimes using a PCI USB board can sound better even with shared IRQs.
You have some valid points regarding the instructions, I looked that the documentation too and decided the key words were “generally” and we “recommend” not don’t do it at all.  So I figured i would try it pushing the configuration and see what happened. My experience has been fine for setting affinity drivers that have IRQs and those that don’t. I did however reason that problems might come if you have two drivers, that share the same IRQ, set to different affinity. I made sure that where there is IRQ sharing all attached drivers get the same mask settings.

One reason that I took the risk of assigning affinity to drivers that do have IRQ is that it seems IntFiltr was developed for tuning servers. Therefore stability is of the upmost concern, for this reason the advice could be a little conservative which is why personally I decided to push the configuration to see what happened. If there is anyone from Microsoft or with deep experience of IntFiltr reading their views would be very welcome.
Ultimately is your call on how you apply IntFiltr but it sounds like you have a good understanding of what it is doing, you just need to be comfortable you can recover from potential problems (eg you have backups and the time to rebuild if something bad does happen).
One last thing, a USB connected drive and mouse are not the best for sound quality if you have a USB sound card. You don’t have a signature set for your posts so I cannot see you setup but if you are not using a laptop, why don’t you use PCI SATA to attach your storage and use a cheap PS/2 mouse ?

Regards,

Nick

[Josef]

Thanks, Nick.

I _am_ using a laptop, indeed, so I have no option of choosing USB ports - there are only 2 physical ones: 1st for USB-SPDIF (older OffRamp model based on M-Audio Transit driver) and 2nd for external Hub with WD HDD and mouse (no PS/2 connections either...).

I think the important think when it comes to USB is never to have other devices on same port: I have tested this myself and, indeed, if I connect OffRamp via Hub it sounds terrible beyond repair. It works good on its own though, but it's really annoying for Intel to have put all USB ports on same IRQ...

There are, however, multiple 'USB Host Controller' devices in Device Manager: I will try disabling devices that share IRQ with OffRamp and see if Windows will switch HDD/Mouse to other 'Host Controller'....

But before that, I guess I should investigate booting from USB stick: that way, if anything bad happens, only the stick needs to be reformatted....

Oh, BTW: Putting affinities on devices without IRQ IMHO is worthless: as there is no IRQ to begin with those settings are ignored. I tried this with M-Audio Transit driver and can see that DPC calls are always serviced on core 0 regardless of affinity settings...

 

[Nick]

Will try this later and let you know how it sounds.

How does it sound? Well, very nice indeed! I've just had my brother over and through headphones (my AKG-1000s are the most revealing I've ever heard), he couldn't tell the difference between vinyl and a 24/192 recording played back on XX. And I'm not sure I can anymore either.

Thanks for all the effort Nick - your tweaks have been superb.

Oh and for anyone who is tempted to try this, it should be totally fine and straight forward - my earlier issues were my own doing and not the SW's. But it is quite laborious setting all the affinities...

Mani.

Mani,
Thanks for the feedback, I am really pleased that you have managed to get such significant changes in the sound of your system, credit is also defiantly due to Marcin as well. I am particularly encouraged by your A/B test with vinyl, that for me is a most significant finding. My system is also has a wonderfully analogue sound but the comparison for me is from memory as my LP12 went a year or two ago (god rest its soul ).

I have been doing some testing on the affinity setting of the three important types of service:
1) Sound card and connection,
2) Storage RAM Disk,
3)and XXHighEnd.

Finding are that generally the sound fills out and tone becomes more “right” when each of these processes has more that one CPU to run on. The improvement very nice to have BUT for maximum resolution one process per CPU seems the best (this is in line with the theory that each software processes should get uncontended immediate access to CPU the moment is called for).

So conflicting dynamics:
Better general sound with more CPUs set but lower resolution
vs
Best resolution with one CPU per process but not the best possible overall presentation.

Conclusion I want more CPUs than I have to test giving each key process 2 or more CPUs ! If you have time (or can pull yourself away from listening to the new setup ;-) ) it would be useful if you could run the hyperthreaded test we talked about on you i5 processer. Something tells me there could be a real sweet spot here wait to be found.

Regards,

Nick.

[Nick]

Oh, BTW: Putting affinities on devices without IRQ IMHO is worthless: as there is no IRQ to begin with those settings are ignored. I tried this with M-Audio Transit driver and can see that DPC calls are always serviced on core 0 regardless of affinity settings...

Josef

Thats intesting, if USB connected drivers without IRQs are defaulting to CPU 0 maybe it would be better to shunt all of the systems background IRQs off to CPU3 then and assign 0,1 and 2 for the music. Hummmm....

Nick.

[PeterSt]

I spent some time observing the 4 core cpu behaviour, and tried to "balance out" things as much as possible. Just a technical approach, but I also think what I ended up with sounds the most normal to me.

So, 2.9GHz per core, Core Appointment Scheme = 3, Player Prio to Low and Thread Prio to Real Time.
Kernel Streaming Special Mode, Driver Buffer Size of sound card = 1024, Device Buffer Size in XX = 1024, Q1 = (1) latency of 32 samples.

Important :
What I now noticed, is that the driver runs in Core #3. IOW, I wouldn't bother much about those interrupt settings, because this is just how it works out with a 4 core processor. Besides that, all the loading stuff is in Core#1 (incurred for by Scheme-3), the Playback Thread in in Core#2 (ditto), and any additional whatever Vista stuff pops up in Core#4. Notice though this does not count for things you start during playback, because at that moment this is not under my control. So that appears "everywhere" (Affinity and "the more stuff" is to all Cores by default).

So ... What you see below in Driver09 is the most balanced and low cpu useage I could find in two hours of time (the combinations are endless of course). Also notice that this is 16/44100 Octo Arc Predition Upsampled (to 32/352800), and the 32 bits internal latency may not be reachable by you even at a lower output sample rate. Don't think "ok, then I make 64 of that 32 samples", because everything changes; not only the Playback Core, but also the Driver Core.
The "Update Speed" in TaskManager is to be set to "High", because otherwise the Driver Core is flattened too much and the various settings won't differentiate (much).

Again, just some technical approach, but as said, I imagine that things sound the most normal at the same time.

Lastly, notice that I used Special Mode because of the additional detail that brings, but also because Adaptive Mode won't bring such a nice cpu graph.
Engine#3 can bring even better pictures, but because of the different working of Q1 *and* the subjectiveness to sound for a certain Q1 setting, I don't think it is useful to approach this in this technical fashion.

Some additional remarks :

Although Scheme-3 appoints Affinity to all processors there's more under the hood, which dictates things to certain processors anyhow. But, for the Driver09 picture I manually put Affinity for TaskManager to Core #1 (careful, because "technically" this is Core#0 but I don't speak like that in here). So, this makes sure it doesn't interfere with the Playback and Driver Core for these pictures and story. But now look at Driver10 below;

What I suddenly learned is that this behaves the same as W7, and the updating of the TaskManager Graph stalls at a track load. This *also* makes comparison with W7 graphs and Vista Graphs tedious, because in the normal situation (TaskManager has affinity to all Cores) it looks like Driver11 below. So, it looks like the loading takes longer, but it is really the Graph which keeps on being updated.
This, while I at first thought it really took longer under Vista, which for me went along with the change of processor (from E6600 to i7/870). Also notice that I applied Nick's "priority tweaks", which *thus* don't end up in W7 behaviour (this needs a bit of upside down thinking), and W7's priorities just *are* dealt with differently.

Hope this is beneficial to someone.
Peter

[manisandher]

If you have time (or can pull yourself away from listening to the new setup ;-) ) it would be useful if you could run the hyperthreaded test we talked about on you i5 processer. Something tells me there could be a real sweet spot here wait to be found.

i5? F-off. It's an i7. (Sorry, a particular scene in 'The Life of Brian' sprang to mind.)

Yeah, I don't think I'm going to be able to stop myself from trying this. It's interesting looking at the Performance Monitor - few IRQs get shunted to CPU1. For example, before setting affinities, Latency Checker ran on CPU1 - now it runs on CPU0. Whatever, the sound is crystal clean now.

Mani.

[Josef]

Thats intesting, if USB connected drivers without IRQs are defaulting to CPU 0 maybe it would be better to shunt all of the systems background IRQs off to CPU3 then and assign 0,1 and 2 for the music. Hummmm....

Yes - In theory, it makes a lot of sense because IRQ is only part of the story - In fact, IRQs most times won't actually _do_ much but rather schedule a DPC call which 'does the real job'.

Unfortunately, AFAIK DPC affinity cannot be influenced by user - it is set in driver code

Still, practice shows (at least for Transit driver) that DPC goes to core 0 all the time and it is sound-driver DPC we care most about as it probably makes sense to make sure it's _not_ interrupted ever!
 
Hence, sound-card IRQ should be 'solo' (because it generates most interrupts by far - assuming you have already made your setup 'quiet') and on a dedicated core but not on core0 because we want sound driver DPC to be un-interrupted at all times.

Again, this is all in theory and just trying to make sense of what is going on: I wish I had a quad & six-core to experiment
 

[PeterSt]

I only now realized that my earlier post ended up in the wrong topic. So I merged it in here now. See a three posts back.

Yes - In theory, it makes a lot of sense because IRQ is only part of the story - In fact, IRQs most times won't actually _do_ much but rather schedule a DPC call which 'does the real job'

Something similar or the same () ... won't a task be scheduled on the same core the IRQ went to ?
This is what I anticipated on a bit with my previous post.

Peter

[Josef]

... won't a task be scheduled on the same core the IRQ went to ?
This is what I anticipated on a bit with my previous post.

Peter

That would be best but unfortunately is not what I saw last night: Most active IRQ was well-balanced between cores 0 & 1, while all DPC calls to MAudioTransit happened on core 0....(It might be specific to this driver though.)

And same thing happened with Foobar so it does not look it's XX-related...

I think I will have to disable all USBs apart from OffRamp connection, apply Nick's affinity tricks and see what happens in that case....