[asterisk-dev] Link reliability issues on DAHDI

[Kevin P. Fleming]

Felipe Bergo wrote:

> To check whether the link was reliable, I wrote a simple application to
> test a repeat pattern of 160 bytes (00 .. 9F) over a clear (audio)
> channel. Link to the source:
> 
> http://pastebin.com/f40704fc1

There are already tools like that in dahdi-tools; pattest, patgen and
patlooptest will do a similar thing :-)

> The setup is a TE205P board on a x86_64 (core2 duo, lots of RAM) running
> CentOS 5.2 and DAHDI 2.0.0rc4 (the latest non-SVN at the time we started
> testing). The 2 E1 ports of the 205P are attached with a 1-foot
> crossover cable. We already tried switching cables -- it's not the cable.

Well, many bugs have been fixed in DAHDI since 2.0.0-rc4, so I'd really
suggest upgrading before spending much more time on this.

> When the system is idle, we get loss of one or a handful of bytes
> occasionally. (in the application above, an error rate of 0.3 to 1.0
> errors/second).
> Whenever there is any disk activity ("/bin/yes > /tmp/file.txt" and hit
> Ctrl+C after a few seconds), the received pattern is full of errors (>
> 20 errors/second)

What buffer policy is your application using for the DAHDI channels,
what size are you setting the buffers to, and how many buffers are you
configuring?

> Can anyone point the reason for this behavior ? Is there any obvious
> mistake in the pattern testing code ? Isn't the board supposed to
> receive and buffer all E1 frames regardless of interrupt activity on the
> PC bus ?

No, the board only 'buffers' one frame worth of data and then bursts it
into memory. If there are any problems that cause bus access to be
delayed, data will be lost.

> Also related: I have tried changing noburst=1 and noburst=0 in the
> wct4xxp module options (,/etc/modprobe.d/dahdi) but dmesg always shows
> the driver coming up in burst mode:
> 
> Nov 12 11:40:44 labcom52 kernel: Found TE2XXP at base address fdeff000,
> remapped to ffffc20000064000
> Nov 12 11:40:44 labcom52 kernel: TE2XXP version c01a016a, burst ON
> Nov 12 11:40:44 labcom52 kernel: Octasic optimized!
> (...)
> Nov 12 11:40:44 labcom52 kernel: Found a Wildcard: Wildcard TE205P (4th Gen)
> 
> Is there any reason for the driver to refuse non-burst mode on this board ?

Yes, the 3rd and 4th Gen firmware for that card only supports burst
mode, IIRC.

> About ELAST errors:
> 
> What is the the intended semantic of the ELAST error on reads and writes
> ? On a write, if the buffers are full/link is busy, isn't the driver
> supposed to block the write instead of returning an error immediately ?

Are you setting the channel file descriptor to non-blocking mode? If so,
this is exactly what you should expect.

-- 
Kevin P. Fleming
Director of Software Technologies
Digium, Inc. - "The Genuine Asterisk Experience" (TM)