This page is part of the GENIUS project.
Evaluation of laboratory computers for use as traffic monitors
CAIA Technical report 020924A, September 2002
Introduction
This report aims to evaluate the suitability of some typical computer configurations for use as network game traffic monitoring devices in a home LAN-based environment. The following sections detail the methods utilised to calibrate the laboratory computers used for capturing and time stamping game traffic packets and lists the results obtained. All computers were tested with bursts of fixed-spaced Ethernet frames from a Smartbits 2000 machine.
Equipment & Testing Setup
- Netcom System Smartbits 2000 Multiport Port/Stream/Layer Performance Analysis System
- Packet Sniffing Computers
- 1.6Ghz P4 Compaq EVO 500 running FreeBSD 4.5
- 1.6Ghz P4 Compaq EVO 500 running Microsoft Windows 2000
- 600MHz Celeron CA810e Intel motherboard running FreeBSD 4.6
- 166MHz Pentium IBM 300GL running FreeBSD 4.6
- 10Mbit/sec CentreCOM AT-MR820TR hub (a real hub, not a switch)
Tests, Results and Discussion
Link speed: 10Mbit/secFrame: 92 bytes Ether/IP/UDP + 4 byte CRC
Fixed-space intervals: 125usec - 100msec
(Interval between end of one frame and start of another)
To timestamp and capture packets:
Tcpdump was run with "tcpdump -n -i fxp0 -w <file>" in each case.
To analyse the captured file:
Tcpdump was run with "tcpdump -n -ttt -r <file>" in each case.
Note: The "-ttt" option causes tcpdump to print out interpacket intervals rather than absolute timestamp values.
Figure 1. A flow of three consecutive packets showing Smartbits' interpacket gap and tcpdump timestamp interval.
The diagram above depicts the differences between interpacket gap that Smartbits uses to generate fixed-interval packets and the timestamps placed on packets by tcpdump. The Smartbits 2000 time interval is between the end of one packet and start of the next, while the difference between consecutive tcpdump timestamps (d1 and d2 as labeled per Figure 1.) is from the start of one packet and start of the next - including the transmission time of the packet itself. The packet length in time (packet transmission time) is (92+4)*8 @ 10Mbit/sec (76.8usec) plus the preamble of 64 bit times, which accounts for the approximately 83 usec constant offset we see between Smartbits setting and the intervals reported by "tcpdump -ttt".
In the results below, some packets appear to be incorrectly time stamped in mirror pairs. In these cases it was only one packet that was stamped incorrectly, as the "tcpdump -ttt" command timestamps relative to the arrival of each packet. E.g. Assume t1, t2, and t3 are the absolute tcpdump timestamps for packets 1, 2 and 3 in Figure 1. Thus we get two interpacket intervals of d1=(t2-t1) and d2=(t3-t2). If t2 is skewed late by the system, then we can see that d1 will be larger than the mean and d2 will be smaller by the mean.
In general, most configurations seemed to perform to an adequate level with only minor variation from the mean interpacket arrival time. It was discovered that some spreading/variation of interpacket arrivals was present with slower CPU-based machines, but the results obtained would be quite suitable for measuring Home LAN-based game traffic (see Results of Various OS/CPU Packet Sniffing Computers). Another interesting observation is the comparison of FreeBSD and Windows operating systems on identical machine configurations (see Figures 3 and 4).
We did notice some peculiar packet timestamping behaviour upon installing a 2nd network card into Intel CA810e-based system. These results are detailed in the following page (see Calibration Tests for Intel CA810e based computer). Note we have not done any further investigation into the exact causes of this. It is advised to bewary of various combinations of computer and networking hardware. Also, be sure to test equipment upon any adding additional hardware/peripherals and prior to any data acquisition.
Summary
In having calibrated the various computer found within the CAIA lab, it was discovered that in general all configurations time stamped the network traffic transmitted to within +/- 27usec on average. Hence, it is possible to build and configure a cheap computer suitable for use as network game traffic monitoring devices in a home LAN-based environment.
An interesting occurrence was also found with one of the computer configurations (Intel CA810e-based machine) whereby a secondary network card caused a regular error to occur in the timestamped packets. As a result, it is important to ensure that all configuration changes are noted and tested prior to use for data acquisition.
| ||||||||||||||||
|
