3.1. ATM Over TCP Setup

If you have no real ATM hardware, you can still exercise the API by using the ATM over TCP ``driver''. It emulates ATM devices which are directly wired to remote devices (i.e. there is no VPI/VCI swapping).

To establish one (bidirectional) ``wire'', become root on both systems (or run both sides on the same system to create two connected ``interfaces'') and run the following command on one of them (let's call it ``a''):

# atmtcp virtual listen

# atmtcp virtual connect address_of_a

Both atmtcps will report on their progress and the kernel should display messages like:

Link 0: virtual interface 2
Link 1: incoming ATMTCP connection from 127.0.0.1

Link 0: virtual interface 3
Link 1: ATMTCP connection to localhost

Multiple ``wires'' can be attached to the same machine by specifying a port number (default is 2812). Note that no AAL processing is performed. It is therefore not possible to receive data using a different AAL (e.g. AAL0) than the one with which the data was sent.

3.2. ZN1221/ZN1225 Tuning

The ZeitNet ZN1221 and ZN1225 adapters use pre-allocated pools of free memory buffers for receiving. Whenever a VC with a certain maximum SDU size is opened for receiving, the corresponding pool is filled with free buffers by the device driver. The adapter removes buffers while it receives data. When the number of remaining buffers falls below a certain threshold, the device driver replenishes the pool again.

The lower and the upper limits for the number of free buffers, and the threshold for adapting to a new data offset (see below for details), can be set using the zntune program. Usage:

zntune [-l low_water] [-h high_water] [-t threshold] itf [pool]

The current settings and some usage statistics can be obtained by invoking zntune without specifying new parameters:

zntune [-z] itf [pool]

The ``Size'' column shows the buffer size in Bytes. The ``Ref'' column shows the number of open VCs using that pool. The ``Alarm'' column shows how many times the number of free buffers has fallen below the low-water mark since the counters were reset. Similarly, the ``Under'' column shows how many times an incoming PDU had to be discarded because the corresponding pool was empty.

The columns ``Offs'', ``NxOf'', ``Count'' and ``Thres'' show the alignment adaption status. ``Offs'' is the offset of user data the driver currently expects in incoming PDUs. For single-copy, receive buffers are aligned accordingly so that data is received at page boundaries. ``NxOf'' is the user data offset of the most recently received PDU, where the offset differs from the currently assumed offset. ``Count'' is the number of PDUs that have been received in sequence with an offset of ``NxOf''. Finally, ``Thres'' is the threshold value ``Count'' has to reach for ``NxOf'' to become the new current offset.

Use the -z option to reset the ``Alarm'' and ``Under'' counters.

3.3. Files in /proc/net/atm/

Some status information about the ATM subsystem can be obtained through files in /proc/net/atm/. The file /proc/net/atm/arp contains information specific to Classical IP over ATM, see section CLIP.

All active ATM devices are listed in /proc/net/atm/devices. For each device, the interface number, the type label, the end system identifier (ESI), and statistics are shown. The statistics correspond to the ones available via atmdiag.

Individual ATM devices may register entries of the form type:number (e.g. eni:0) which contain device-specific information.

The files /proc/net/atm/pvc and /proc/net/atm/svc list all PVC and SVC sockets. For both types of sockets, the interface, VPI and VCI numbers are shown. For PVCs, this is followed by the AAL and the traffic class and the selected PCR for the receive and the transmit direction. For SVCs, the SVC state and the address of the remote party are shown. SVCs with the interface number 999 are used for special control purposes as indicated in the ``State'' column.

Furthermore, /proc/net/atm/vc shows buffer sizes and additional internal information for all ATM sockets.

3.4. ATM Diagnostics

Various counters of the ATM device drivers can be queried with the atmdiag program. See the corresponding man page for details.

3.5. SONET Diagnostics

The SONET diagnostics tool can be used to monitor link performance and to simulate errors. In order to get current SONET statistics, run it with the ATM interface number as the argument, e.g.

% sonetdiag 0

The counters can be reset with the -z option:

# sonetdiag -z 0

The following network failures can be simulated:[1]

A failure is enabled by adding the corresponding keyword on the command line. The failure is cleared by prefixing the keyword with a minus sign, e.g.

a# sonetdiag -z 0 >/dev/null
b# sonetdiag -z 0 >/dev/null
a# sonetdiag 0 los
a# sonetdiag 0 -los
b# sonetdiag 0 | grep BIP
Section BIP errors:      56200
Line BIP errors:           342
Path BIP errors:           152
a# sonetdiag 0 | grep FEBE
Line FEBE:                 342
Path FEBE:                 152

If any diagnostic error insertions are active, their keywords are shown when sonetdiag is used to obtain statistics. Note that some error insertions may be automatically switched off by the hardware.