ATM Latency Measurements

These results come from a series of latency measurements on the ATM loopback connection from DTU/Lyngby to Aalborg University.

The most direct method of measuring latency is to time how long it takes to transmit a packet (or series of packets) from one system to another. A simple way of doing this is to timestamp the transmitted data, and then to compare the value of the timestamp with the time of arrival in the receiving system. In order for this to give an accurate measurement, however, the clocks in the sending and receiving systems must be exactly synchronised. The method used to measure latency in these experiments has therefore been to time the transmission of small packets in a round trip experiment from one system to another and back to the originating system. This has the disadvantage that it cannot reveal any differences which there might be between transmission in the two directions, but the timing is more accurate, so on the whole this method is to be preferred.

As in the jitter experiments, the latency experiments all used a loopback connection communicating via AAL-5 over an ATM PVC set up to give a 1 Mbit/s CBR service. Each sequence of measurements followed the scheme:

This was repeated for various sizes of packet at the AAL-5 level, ranging from very small (a single ATM cell) to bigger than an MTU (i.e. >8192 bytes).

Results on Local Area ATM

Corresponding to the jitter measurements described above, a series of latency measurements was made using a local area loopback configuration: Data from a work station at DTU was sent to the local ATM switch and from there straight back to the workstation. With the workstation performing "normal" tasks, the measured round trip times for various packet sizes were as follows:

The general behaviour observed in this case is that the latency rises stepwise with packet size, with steps every 48 octets. However, there are some marked variations on this theme, involving large excursions from this general behaviour. This is particularly noticeable at small packet sizes, but can be seen even for the largest packets in the form of small spikes on the curve. It should here be pointed out that each point on the curve is the average of 10 measurements, so that individual measurements with even more marked deviations from the general behaviour have been observed in the course of the experiment.

The next series of measurements was therefore made with minimum load on the work station. As in the jitter measurements, all OS daemons and other user processes were killed prior to starting each series of measurements, so that the test program ran as the only activity on the computer. With this setup, the measured round trip times for various packet sizes were as follows:

This configuration results in a marked decrease in the spikes and other excursions in the latency curves. Closer investigation revealed that in particular a group of processes which are activated at regular intervals were responsible for most of the spikes, while a random selection of other activities gave rise to the other phenomena.

Results on Wide Area ATM

As a final experiment, the Wide Area ATM was used in loopback mode with the sending and receiving workstation operating at minimum load. The intention of this experiment was to check whether the wide area network itself introduced anomalies. The assumption here is that such anomalies would be (more) easily visible in the minimum load configuration of the workstation. The results were as follows:

With this configuration, and with the scale of graph used in the figure, only very small variations from a smooth and linear curve are visible. Again, the use of minimum load seems to be the key to good behaviour, while the network itself seems to have very little effect. Evidently, stressing your work station is not a good way to get the most out of it -- there must be a moral in this somewhere!