[Asterisk-Users] Dual T400P, SMP, performance issues

[Alberto Bertogli]

On Thu, Jun 12, 2003 at 07:23:42PM -0500, Alex Zarubin wrote:
> Zaptel was compiled with -D__SMP__
> 
> We've installed irqbalance and the picture improved a lot
> (thanks to Jared Smith). Do you still see problems in our /proc/interrupts?

Well, maybe i'm nitpicking, but there's a subtle issue there.

You mentioned that the machine is dual processor, but you see 4 CPUs there
due to hypertheading support into your Xeons.

Now, the thing is that IMHO you should try to balance the IRQs only
between the two real CPUs, leaving the HT cores aside; it might show some
improvement.

Even better, you might also want to try out splitting the interrupts among
each processor, according to the card. Like binding interrupts from card0
to cpu0 and from card1 to cpu1; but really don't remember if you can do
such things in 2.4.


Have you tried using 'vmstat' to monitor interrupt rate? Maybe it's not
that high, and your problem lays somewhere else.. it'd be a very good
thing to take look at. After all, a Pentium 2 machine can easily handle
full 100Mbit load so it should, in theory, cope with your 8 channels,
even if the interrupts are generated a bit more frequently.


BTW, does anyone know if the zapata drivers have been tested with preempt?


> The big issue for us now is that after 24+ hours of the test load PRI->SIP
> our Dell PE2650, dual 2.6 GHz Xeon, 2 Gb RAM, 2 T400P, 2.4.20-18.7smp #1 SMP
> stops responding to anything.

Well, no 'expertise' here but I'd recommend you to try vanilla 2.4.21-rc
(the last one, IIRC it's about 9 but poor Marcelo is being mailbombed with
patches so it's harder to keep track of -rc =); and if you can reproduce
the problem with it, then post to lkml.

Testing 2.5 would be great too, but I highly doubt that zapata drivers
work with it (at least last time I tried they doesn't even work with
latest 2.4 if HDLC is enabled, due to kernel HDLC internal changes).


A good idea is to enable SysRq (from the kernel hacking menu) and when it
locks up (if it does) try to use it to see 'how much of it is death',
printing the stack traces, task lists and memory state.

Pinging it might also be useful (yeah, that might sound dumb but it's a
good sign if it responds to pings because it means that interrupts and
some parts of the kernel are still pretty alive).


Thanks,
		Alberto