PBX in a Flash for Newbies

Performance Testing Dahdi Hardware


Performance Testing Dahdi Hardware

dahdi_speed test

dahdi_speed runs a simple 100% CPU loop for 5 seconds to see how many loops are performed. A larger number is better. At the Linux prompt run the command "dahdi_speed".

root@pbx:~$ dahdi_speed

Here's some sample results to compare your system to:

The following table can be sorted by clicking on the table column heading:

Description ztspeed Results Bogomips Cards
Dell P4 259084 2-x100p
gPC2 489661 none
Dell SC440 1239995 none
gPC2 488259 3002
Dell Poweredge T100 1244042 4000
Intel Atom 230 1.6 Ghz 867767 none
gPC2 474516 none
1.2 Ghz AMD Athlon 542632 none
Dual Xeon 2.4 Ghz 352601 FXO/FXS card
P4 3 Ghz 962651 6003 FXO/FXS card + T1 Card
Dual Atom 330 @ 1.6 Ghz 880698 3192

It's interesting to see that just pure cpu speed doesn't make a good dahdi platform. The PCI bus and interface to it make a huge difference. Another important point that will be covered later is IRQ sharing and its effect on performance.

Bogomips

To find your bogomips (a measurement of your cpu speed), type "dmesg | less" at the Linux command prompt.

root@pbx:~$ dmesg | less

When the computer is booting Linux, one of the things it does is calculate the relative cpu speed. The command dmesg displays most of the boot messages that fly past on the screen. The "| less" command shows the messages one screenful at a time. Otherwise all you'll see is a blur. Use the page up/down buttons or spacebar to view the next screens (q to quit). About 6 screenfuls in is the bogomips rating on the right side of the screen.

Performance Testing

The dahdi_test program runs a timing test in a loop and prints the result of each loop. The test is as follows:

It reads 8192 bytes from the Dahdi timer device (/dev/dadhi/pseudo). This should take exactly 8000 ms . It uses calls to gettimeofday(2) before and after that read to check that indeed exactly 8000ms have passed.

Acceptable values range from 99.975% to 100%. With values lower than 99.975%, you can expect problems.

Type dahdi_test at the Linux command prompt. You should run it for a long period of time (5 minutes minimum) and throughout the day. Here's good results from a dahdi_test:

Here's bad results (less than 99.975%):

In addition to consistent bad results, you can have intermiddent problems also. You would use dahdi_test's -v option. This gives you a test by test comparison of what is expected and what the result were. This site gives you more information on using the -v option: How to solve TE122 Stability Issues

Troubleshooting Bad dahdi_test Results

The number one reason for bad dahdi_test results is pci bus problems which result from sharing of IRQs. Dahdi devices do NOT like to share IRQs with other devices. Dahdi devices are time sensitive devices and cannot be fighting for the PCI bus with other devices. To monitor the PCI bus, use the "lspci -vb" command at the Linux command prompt. You can direct the output one screen at a time by using this command "lspci -vb |less" or direct it to a text file "lspci -vb >pci.txt"

In this computer, the two digium Dahdi cards show up as Tigerjet 3xxx modem/ISDN cards. This is because the Dahdi cards use the Tigerjet PCI bus interface chip. Notice that both cards are sharing their IRQs (9 and 10). One with the audio controller (IRQ 9) and the other with the serial controller (IRQ 10). This will cause a low dahdi_test rating and poor audio quality or dropped audio.

Solution

The solution is not that easy anymore, here's some suggestions:

  • Disable onboard peripherals and interfaces that are not used by the server: USB ports, serial ports, sound card, floppy drive, parallel port, etc.. This will free up some IRQs and may fix your IRQ sharing problem.

  • Some motherboards have a bios that allows you to set the IRQs for each PCI slot. Take the bios setting for the PCI bus off of automatic and manually set the IRQs. This was common with older motherboards. Newer motherboards it is not so common.

  • Turn off the PC and move the Dahdi cards to different PCI slots. Reboot and test. You may have to fiddle around with the order of cards in the PCI slots to find the "right" order where there are no IRQ sharing.

  • If you have multiple CPUs, you can assign IRQs to specific CPUs to load balance the PCI bus. It is actually easier than it reads.

  • You can give the Dahdi cards a higher priority by changing the PCI latency for it. I haven't tried it yet, here is how you would change it: Drivers, IRQs, and PCI latency


Go to the

Introduction
to Networking

Online Book

Go to the

PBX in a Flash

Home Page

Go to the

FreePBX

Home Page

Return to the

PBX in a Flash
for Newbies

home page

Copyright April 2008 - Eugene Blanchard