[Asterisk-Users] Line Noise HELP!

[Damian Funnell]

Hi Rich,

Hear your point about the trace and all, will try and figure something 
out.  Will also look at logging debug messages.

We did the unthinkable and purchased a support incident through Digium 
and they have zeroed in on the zttest output, as per the info below 
(I've pasted in an excerpt from their email in case anyone else finds it 
useful).  Not sure if this is the cause of our problem or not, as I 
don't understand whether the TDM card is used as a timing source for 
calls over CAPI, but will look at getting zttest output up regardless.

Have to say that I am pretty impressed with Digium support so far - the 
engineer even rang me in New Zealand to follow up on their email and to 
inform me that I still have 45 minutes of my hour left to use.

Cheers,
Damian.

Excerpt of email from Digium support:

Digium does not support CAPI or BRI, either freely or commercially.

We can only provide support for you Digium TDM400P card.

Your zttest output is extemely low.  We are looking for nothing less
than 99.98%.  If you are receiving 99.96% this will cause major
problems.  Have a best output of 99.975% is really low.

Please ensure that you are running either Asterisk Release 1.07, Zaptel
Release 1.07, and Libpri Release 1.07 (Libpri only required if using a
PRI) from www.asterisk.org or Asterisk CVS Stable/HEAD, Zaptel CVS
Stable/HEAD, and Libpri CVS Stable/HEAD (Libpri only required if using a
PRI) as of the current date from Digium's CVS server.  You may obtain
instructions on downloading CVS Stable/HEAD from Digium's CVS server by
visiting the download area on www.asterisk.org.

Please verify that your Digium hardware is not sharing an IRQ on your
system.  You can accomplish this by running "cat /proc/interrupts".  Do
not solely rely on "cat /proc/interrupts" to determine whether your
Digium hardware is sharing an IRQ on your system.  Make sure your Digium
hardware is on its own IRQ by itself and that it is taking interrupts. 
You can determine whether it is taking interrupts from the 2nd column of
output from "cat /proc/interrupts".   This should be something other
than zero.  You will also need to verify that your Digium hardware is
not sharing an IRQ by examining the output after running"lspci -v" and
"lspci -vb".  Using lspci is the best way to determine whether or not
your Digium hardware is sharing an IRQ on your system.  Please verify
that all Digium hardware is on its very own IRQ by itself.  You may need
to disable unnecessary hardware on your machine such as sound
controllers, USB controllers, extra ethernet controllers, firewire,
parallel ports, and/or serial ports.  You should try moving and swapping
our card to different PCI slots in order to get it on it's own IRQ. 
Some BIOS's will allow you to specify an IRQ for each PCI slot and/or
onboard devices.

If you are running an IDE hard drive please verify that you are using
DMA mode with a UDMA setting of no lower than 2 or higher than 3.  UDMA
mode 2 is ATA33.  UDMA mode 3 is ATA44.  This can be done using hdparm.
 We suggest using "hdparm -d 1 -X udma2 -c 3 /dev/[IDE Device]".  You
can check the status using "hdparm /dev/[IDE Device]" and "hdparm -i
/dev/[IDE Device]".  If you make modifications to your IDE hard drive
settings they will only be kept until you reboot.  You will need to add
the hdparm command you executed to one of your distribution's startup
scripts.  This way the IDE hard drive settings will be updated on each
reboot.

You can check whether or not your Digium hardware on your system is
experiencing IRQ misses by using the zttest application which should be
located in yourzaptel source directory.  Do not solely rely on zttest to
determine whether you are having IRQ misses with your Digium hardware on
your system.  Optimally,we are looking for output of 100% from zttest. 
Our cards will function properly as long as they do not report back less
than 99.98%.  Some people have reported no apparent problems with output
as low as 99.975%, while others will have many apparent problems with an
output as low 99.975%.  You are almost guaranteed to have many apparent
problems with an output lower than 99.975%.  We strongly suggest doing
everything possible in order to obtain atleast 99.98% output from
zttest.  I would watch the output over a 5 minutes period to check for
spikes on intervals.  You may also look for IRQ misses using the zttool
application.  Do not solely rely on zttool to determine whether you are
having IRQ misses with your Digium hardware on your system.  This
application should be built while compiling zaptel.  zttool requires the
libnewt development package to be installed on your system in order to
compile properly.

IRQ misses with your Digium hardware can be due to I/O problems on your
system.  You may test if you are having I/O problems on your system by
running "hdparm -t /dev/[Hard Drive Device]".  This will causes massive
amounts of I/O on your system.  The symptoms of an I/O problem on your
system could be cracklingand/or static on the line while running "hdparm
-t /dev/[Hard Drive Device]".  If you are having an I/O problem on your
system and run this command it could result in dropped calls
temporarily.  If you are experiencing those symptoms while running
"hdparm -t /dev/[Hard Drive Device]" it is likely that you havean I/O
problem on your system.  We would suggest using an IDE harddrive rather
than SCSI or SATA in order to configure your hard drive to UDMA2. 
Configuring a SCSI or SATA hard drive to UDMA2 is not possible.  This is
only possible on an IDE hard drive.  Do not solely rely on "hdparm -t
/dev/[Hard Drive Device]" to determine whether or not you have an I/O
problem on your system.

Please ensure that you are not running X-Windows, frame-buffer, or
serial console, as these will cause problems with our hardware.  You can
disable frame-buffer by supplying the "vga=normal" option to your kernel
at boot time.  Frame-buffer may start your console with a high
resolution and a logo that is alongthe top of the screen.

If you are still having IRQ misses with our hardware you could try
booting your kernel with "acpi=off" and/or "noapic" to disable ACPI
power management andAPIC.  These has been known to cause interrupt
sharing problems as well.

If your system supports Hyper-Threading Technology, you should disable
it in your BIOS to see if it resolves your problems.

If these suggestions do not resolve your issue, please call
1-877-LINUX-ME to provide us with remote root access to your Asterisk
server.  This will allow us to further debug your problem.  You may
provide us this information by email if you prefer.


FFF Managed Technology Ltd
60 Cook St
P.O. 6368 Wellesley St
Auckland
t +64 9 356 2911
f +64 9 358 9070
m +64 21 415 297
w www.fff.co.nz



Rich Adamson wrote:

>>Thanks for that Rich.  Etheral trace is going to be almost impossible 
>>for various reasons, but will try the other two options.
>>
>>Can't find much online re. debugging - any chance of killing the box by 
>>turning this on?
>>
>>SIP show channels and the various CAPI show commands do not show 
>>anything out of the ordinary when the problem occurs.
>>    
>>
>
>In order for anyone to help identify the noise problem, you really
>are going to have to find a way to capture some data, otherwise
>we're all spinning our wheels and guessing.
>
>To implement debugging, look at /etc/asterisk/logger.conf and add
>the keyword 'debug' like:
> messages => notice,warning,error,debug
>Adding that keyword requires that * be stopped and restarted to take
>effect. That tells asterisk to log all debug statements (that are
>embedded in asterisk source code) to write to /var/log/asterisk/debug 
>file.
>
>That debug file will grow to a very large size rather quickly, so
>you need to pay attention to available disk space, etc.
>
>When the noise problem occurs, note the specific system "time", and
>take a look at /var/log/asterisk/debug to see what was happening
>around that time. Once you've captured at least some data, you may
>want to remove the debug statement.
>
>If you haven't tried some of the other cli debug tools, you might
>want to do "help sip debug", "help rtp debug", etc.
>
>If you can't run ethereal on the system with the problem, there are
>other tools like tcpdump, etc, that can be used to capture packets.
>
>
>_______________________________________________
>Asterisk-Users mailing list
>Asterisk-Users at lists.digium.com
>http://lists.digium.com/mailman/listinfo/asterisk-users
>To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
>
>
>  
>