# irqbalance

## redwood

I have a system with an 8-core AMD Opteron cpu:

Linux apps 3.2.1-gentoo-r2 #1 SMP Wed Feb 8 16:57:46 EST 2012 x86_64 AMD Opteron(tm) Processor 6128 AuthenticAMD GNU/Linux

with sys-apps/irqbalance-0.56 installed.

```

# cat /proc/interrupts

           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7       

  0:       1470          0          0          0          0          0          0          0   IO-APIC-edge      timer

  1:          8          0          0          0          0          0          0          0   IO-APIC-edge      i8042

  3:        122          0          0          0          0          0          0          0   IO-APIC-edge      serial

  4:     272282          0       3738          0          0          0          0          0   IO-APIC-edge      serial

  8:        115          0          0          0          0          0          0          0   IO-APIC-edge      rtc0

  9:          0          0          0          0          0          0          0          0   IO-APIC-fasteoi   acpi

 12:        112          0          0          0          0          0          0          0   IO-APIC-edge      i8042

 16:          2          0          0          0          0          0          0          0   IO-APIC-fasteoi   ohci_hcd:usb3, ohci_hcd:usb4

 17:          0          0          0          0          0          0          0          0   IO-APIC-fasteoi   ehci_hcd:usb1

 18:         33          0          0          0          0          0          0          0   IO-APIC-fasteoi   ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7

 19:          2          0          0          0          0          0          0          0   IO-APIC-fasteoi   ehci_hcd:usb2

 22:  415878177    5550877          0          0          0          0          0          0   IO-APIC-fasteoi   ahci, wctdm

 23:  243733904  159384261          0          0          0          0          0          0   IO-APIC-fasteoi   wctdm

 42:   74834883          0          0          0          0          0          0          0   PCI-MSI-edge      eth0-rx-0

 43:  123156876          0          0          0          0          0          0          0   PCI-MSI-edge      eth0-tx-0

 44:          2          0          0          0          0          0          0          0   PCI-MSI-edge      eth0

 45:     202199          0          0          0          0          0          0          0   PCI-MSI-edge      eth1-rx-0

 46:          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth1-tx-0

 47:          2          0          0          0          0          0          0          0   PCI-MSI-edge      eth1

NMI:          0          0          0          0          0          0          0          0   Non-maskable interrupts

LOC:   73689557   59131664   52119811   50127734   51629248   49269787   50580698   48191366   Local timer interrupts

SPU:          0          0          0          0          0          0          0          0   Spurious interrupts

PMI:          0          0          0          0          0          0          0          0   Performance monitoring interrupts

IWI:          0          0          0          0          0          0          0          0   IRQ work interrupts

RES:   48812841   59172066   55708881   54394653   42595713   43102434   43350052   42300177   Rescheduling interrupts

CAL:      49888      53938      55762      56389    6222359      54555      50423      54612   Function call interrupts

TLB:    1467252    1522657    2180647    1902743     734679     760770    1034994     604246   TLB shootdowns

TRM:          0          0          0          0          0          0          0          0   Thermal event interrupts

THR:          0          0          0          0          0          0          0          0   Threshold APIC interrupts

MCE:          0          0          0          0          0          0          0          0   Machine check exceptions

MCP:       1349       1349       1349       1349       1349       1349       1349       1349   Machine check polls

ERR:          0

MIS:          0

```

Is this the way a properly balanced SMP system is supposed to look?

There's this SUSE page discussing irq balancing:

http://www.alexonlinux.com/smp-affinity-and-proper-interrupt-handling-in-linux

and it says that you need to disable CONFIG_CPU_HOTPLUG in order to get proper irq balancing.

I'm running kernel-3.2 and when I enable an SMP system, 

```

CONFIG_X86_64_SMP=y

CONFIG_USE_GENERIC_SMP_HELPERS=y

CONFIG_SMP=y

# CONFIG_X86_VSMP is not set

# CONFIG_MAXSMP is not set

CONFIG_PM_SLEEP_SMP=y

CONFIG_HAVE_TEXT_POKE_SMP=y

CONFIG_SCSI_SAS_HOST_SMP=y

```

CONFIG_CPU_HOTPLUG is automatically enabled.

I have an asterisk+dahdi+FreePBX running on this computer, and after upgrading asterisk to 1.8.8.2

```

     Tue Oct 25 21:10:22 2011 >>> net-misc/asterisk-1.8.7.1                                                                 

     Wed Dec 14 20:48:20 2011 >>> net-misc/asterisk-1.8.7.2                                                                 

     Wed Jan 25 15:34:30 2012 >>> net-misc/asterisk-1.8.8.2                                                                 

     Wed Feb  8 14:44:43 2012 >>> net-misc/asterisk-10.1.0

```

I ran into voice problems on calls coming from the PSTN through  the  TDM400P telco cards, where the voice on the PSTN  intermittently would become choppy but the PSTN party could hear me just fine. 

So I upgraded dahdi

```

     Wed Jun  1 23:58:33 2011 >>> net-misc/dahdi-2.4.1                                                                      

     Fri Jul 29 09:29:32 2011 >>> net-misc/dahdi-2.4.1-r1                                                                   

     Thu Feb  2 11:06:47 2012 >>> net-misc/dahdi-2.5.0.2-r2

```

But nothing improved -- and the 2.4.1 series has been removed from the voip overlay.  

I did track down the 2.4.1 ebuild but it could no longer download a necessary patch file -- 

so I can't downgraded dahdi if there's a problem with the 2.5 version (even though it's marked stable)

I also upgraded asterisk to the testing 10.1 series to see if that fixed the issue, but it didn't.

I have two TMD400P cards in the computer:

```

# dahdi_scan

[1]

active=yes

alarms=OK

description=Wildcard TDM400P REV I Board 5

name=WCTDM/4

manufacturer=Digium

devicetype=Wildcard TDM400P REV I

location=PCI Bus 03 Slot 02

basechan=1

totchans=4

irq=23

type=analog

port=1,FXS

port=2,FXS

port=3,none

port=4,none

[2]

active=yes

alarms=OK

description=Wildcard TDM400P REV I Board 5

name=WCTDM/4

manufacturer=Digium

devicetype=Wildcard TDM400P REV I

location=PCI Bus 03 Slot 03

basechan=5

totchans=4

irq=22

type=analog

port=5,FXO

port=6,FXO

port=7,FXO

port=8,none

```

The 1st card on IRQ23 with 2 modules to connect analog phones, shares an interrupt with the AMD SATA ahci driver,

but I'm not really using this card anymore, since everyone now has VOIP phones.

The 2nd card on IRQ22 has 3 modules connecting to the 3 trunk lines from the PSTN. It doesn't appear to share

any irq with anthing else. I'm using OSLEC software line echo cancellation, 

but  the choppiness isn't  an echo problem as far as I can tell.

The problem appears intermittent -- so I thought maybe  the system is doing something randomly which is interfering 

with the TDM400P cards. The dahdi driver needs 1000 interrupts/sec to function properly.

So i tried "cat /proc/interrupts ; sleep 10; cat /proc/interrupts"

```

 23:  243733904  160946179

 23:  243733904  160956183

```

which gives a difference of 10004 interrupts in 10 sec or 1000.4 interrupts/sec which is good.

I also re-ran fxotune but no change.

I'm running shorewall firewall -- there was a suggestion in the asterisk ebuild to disable connection tracking for sip,

so I added to /etc/shorewall/start:

```

modprobe -r nf_nat_sip        &> /dev/null

modprobe -r nf_conntrack_sip  &> /dev/null

modprobe -r nf_nat_h323       &> /dev/null

modprobe -r nf_conntrack_h323 &> /dev/null

```

And for good measure I disabled connection tracking on anything iax/sip/rtp/srtp related:

```

# cat /etc/shorewall/notrack

FORMAT 2

#ACTION         SOURCE          DESTINATION     PROTO   DEST            SOURCE  USER/

#                                                       PORT(S)         PORT(S) GROUP

NOTRACK          loc             192.168.1.0/24     tcp     5038 # AMP -- Asterisk Manager Protocol

NOTRACK          loc             192.168.1.0/24     udp     5036 # iax

NOTRACK          loc             192.168.1.0/24     udp     4569 # iax2

NOTRACK          loc             192.168.1.0/24     udp     5060 # sip

NOTRACK          loc             192.168.1.0/24     tcp     5060 # sip Some SIP servers need tcp as well

NOTRACK          loc             192.168.1.0/24     udp     5061 # sips

NOTRACK          loc             192.168.1.0/24     tcp     5061 # sips

NOTRACK          loc             192.168.1.0/24     udp     10000:20000     # rtp

#

NOTRACK          $FW             192.168.1.0/24     tcp     5038 # AMP -- Asterisk Manager Protocol

NOTRACK          $FW             192.168.1.0/24     udp     5036 # iax

NOTRACK          $FW             192.168.1.0/24     udp     4569 # iax2

NOTRACK          $FW             192.168.1.0/24     udp     5060 # sip

NOTRACK          $FW             192.168.1.0/24     tcp     5060 # sip Some SIP servers need tcp as well

NOTRACK          $FW             192.168.1.0/24     udp     5061 # sips

NOTRACK          $FW             192.168.1.0/24     tcp     5061 # sips

NOTRACK          $FW             192.168.1.0/24     udp     10000:20000     # rtp

```

Finally, there is a newer 2.6 version of dahdi available, but it's not yet in portage. 

I copied the 2.5 ebuild to dahdi-2.6.ebuild, rebuilt the manifest/digest, but the 2.6 would compile for me.

Thanks in advance for any ideas on what to try.

----------

## Ormaaj

Last I checked, irqbalance was of very limited usefulness on a non-NUMA system. The most recent versions didn't do anything but initially set up your IRQs, and then quit. I don't think it's needed on a system with a single CPU node.

----------

