[Asterisk-Users] Line Noise HELP!
Paul
junk at irqx.com
Tue Apr 12 14:47:22 MST 2005
Damian,
Cheers to you for buying that support hour and posting their response.
Hopefully we all can come to a solution for this pesky problem and in a very
timely manner. I will try all of the suggestions and post any solutions I
find. I made a call today on the SIP phone and it was clear for abou 45
seconds and then went to static/line noise for about 3 seconds and then
returned to normal. The remaining 30 - 60 seconds of the conversation was
normal. I'm wondering if maybe it has to do with network congestion. I
called the SIP phone from a separate landline and listened and waited for
the static...it never came. I wish the problem was less sporadic. Thanks
again for your post.
Cheers,
Paul
-----Original Message-----
From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Damian Funnell
Sent: Tuesday, April 12, 2005 14:02
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [Asterisk-Users] Line Noise HELP!
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
>
>
>
>
>
_______________________________________________
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
More information about the asterisk-users
mailing list