[Linux-ATM-General] pdu corruption with 5575 cards

[Massey, J. <James.Massey@Goodrich.com>]

Hi,

=20

I have been doing some back to back testing with Interphase 5575 ATM
adaptors on Linux and am receiving corrupt PDU packets (atmdiag says no
packet drop).

Test Setup
Data is transmitted from a test system containing three 5575 adaptors to
a target system containing three 5575 adaptors.

The test system reads data from a file which is converted to PDU packets
and transmitted from the test system (using the AAL5 protocol) to the
target system.
The test system is connected directly to the target system (no switch).=20

Adaptor 0 transmits on 1 VC @ ~0.1MB/sec
Adaptor 1 transmits on 2 VCs @ ~5.3 MB/sec per VC
Adaptor 2 transmits on 3 VCs @ ~5.3 MB/sec per VC

The PDU size transmitted on Adaptor 0 is relatively small (varies around
a few hundred bytes) and the other Adaptors transmit PDUs of sizes of
~4bytes -8Kbytes.

The target system receives packets via a multi-threaded C++ application
which runs at real time priority.=20

The application receives PDUs from each VC via a socket using the Linux
ATM API.



Packet Drop
Packets received appear to have corrupt headers.=20

The test application attaches a sequence number to each PDU transmitted.

I am seeing sequences like the following:

Tx        Rx

1          1

2          2

3          5 ------ incorrect seq number

4          4

5          5

It appears that at some point PDUs later in the stream are writing over
PDUs earlier in the stream.

The sequence numbers at transmission and reception are logged on the
write and read calls to/from the ATM socket which suggests that the
corruption may be occurring in the ATM stack or driver.=20

Has anyone seen this problem?

=20

ATM Socket setup

The ATM sockets (transmit and receive) are setup to use the UBR class
with a max_sdu size of 8192 for each channel.=20

The max_pcr is set for each channel:

The VC on adaptor 0 is set to 2% max_pcr

The three VCs on adaptor 1 are each set to 33% max_pcr

The two VCs on adaptor 2 are each set to 33% max_pcr

where max_pcr is 352768.

=20

Transmission Problem?

I currently believe the problem is with the transmission because I have
another test system which transmits on 4575 (PMC equivalent of 5575)
cards from a VME based system and the target system does not indicate
sequence number problems.

=20

Introducing a sleep between calls to 'write' on the ATM sockets causes
the sequence number problem to disappear.

The problem also goes away when the max_pcr value is modified to
throttle the bandwidth used by the ATM card. (The ATM Linux
documentation says setting max_pcr has no effect with UBR it appears to
work)

=20

Is there buffering in the ATM stack? i.e. if the test application is
looping round writing to the socket and the card is sending data at a
slower rate does the data written to the socket get buffered up or is it
just lost? I am not seeing any bad return codes from the socket write
call.=20

=20

The test and target systems are running Suse Enterprise Linux 9 and the
hardware is an IBM 366 (4 processor, 8GB RAM).

Any suggestions?

James Massey=20

=20