V3.0 Oct 2010
1
This note describes several programs used for investigating the end-to-end performance of LANs
MANs and WAN. The programs use the socket interface in a simple way and do not require root privileged. The test programs (previously called udp_*) have been updated and the functionality extended. There are now two client programs and a common responder or server program and they are used in pairs: udpmon_req udpmon_resp
Measures the request-response latency between two systems using UDP packets and can also provided histograms of the request-response latency in 1 us bins. udpmon_bw_mon udpmon_resp
This gives an estimate of the BW found on the route between the two end nodes, the packet loss and packet re-ordering. It also measures the inter-packet jitter at the receiver and provides an estimate of the variation of the 1-way delay between the two end systems.
The code has been tested mainly with Linux running on Intel and AMD CPUs with various kernels.
However several programs make use of a fine grain timer based on the Pentium cycle counter and are thus platform specific. (These programs use the StopWatch_*() routines.). From version 2.3-2 onwards, the code and protocol have been extended to operate on systems using the 64 bit Intel Itanium
CPUs and later on both Intel and AMD 32 bit and 64 bit systems.
In some of the test programs Control-c is used to display the current status and Control-z is used to terminate the program. Special behaviour is noted under each program as appropriate.
Related programs in the udpmon_extra package provide the following tools: udpmon_send
Will send a stream of carefully spaced UDP packets. udpmon_recv
Will receive UDP packets and report losses. udpmon_bw_multi
Used in pairs with udpmon_resp, this allows measurement of the bandwidth of multiple simultaneous
UDP streams. It is controlled by udpmon_control. udpmon_control
This program controls multiple udpmon_bw_multi - udpmon_resp pairs.
A further set of programs, TCPmon may be used to measure the request-response latency between two systems using TCP packets and giving an estimate of the achievable TCP throughput between the two end nodes when single & parallel TCP links are used to send the data; the CPU load and interrupts are also measured.
1 The University of Manchester
1

udpmon is formed from two tarballs: libhj-x.y.z.tar.gz and udpmon-a.b.c.tar.gz.
When unpacked, the libhj tar file will create a directory called libhjversion e.g. libhj-4.2.5
. The tar file may be unpacked with the command: tar zxf libhj-4.2.5.tar.gz
.
To make the libhj library, change the current directory to the libhj directory just created and then run configure to build the Makefile.
./configure --prefix=$HOME
The build and install the test programs with the following: make clean make install
An easy way to do this is to run the README file with
./README
The make install step creates the directory $HOME/lib (or $HOME/libAMD64 if it is a 46 bit machine), and places the library there.
When unpacked, the udpmon tar file will create a directory called udpmonversion e.g. udpmon-1.2.3
. The tar file may be unpacked with the command: tar zxf udpmon-1.2.3.tar.gz
.
To make the udpmon programs, change the current directory to the udpmon directory just created and then run configure to build the Makefile.
./configure --prefix=$HOME --with-hj-location=$HOME
The build and install the test programs with the following: make clean make make install
An easy way to do this is to run the README file with ./ README
The make install
step creates the directory $HOME/sbin, if required, and places the udpmon programs there.
The udpmon programs use UDP port 14233 by default, so this port needs to enabled on any firewall and the hosts used.
A suitable entry (all one line) for the iptables file is:
-A RH-Firewall-1-INPUT -p udp -m udp --dport 14233 -j ACCEPT
The Request-Response tests measure the time taken to send a "Request" to a remote host and obtain a
"Response" as a function of the size of the "Response" message. The length of the "Request" message can be varied, but normally, the request will be fixed at 64 bytes long. The total time for a series of
Request-Responses, typically 1000 -10000, is measured using the real time clock of the sender via
2

gettimeofday() ; and the individual round trip latency times are also measured using the Pentium
CPU cycle counter using the
StopWatch_*() routines [1]. These values are presented as the average, min & max times and may be histogrammed.
The Request-Response latency vs message size plots will show the total round trip latency as a function of the user data length. The time for the “Request” should be constant so one would expect the plots to be described by a linear equation [ref ATLAS note]. Assuming all the interfaces work in store and forward mode, (some 100 Mbit Ethernet PCI cards allow ripple through or wormhole forwarding) the slope s is given by the sum of the inverse transfer rates of each hop of the end-to-end path: s

 data paths

1
For two systems connected back to back, the hops include:
sender Mem-mem copy(s) + sender pci + Ethernet + receiver pci + receiver mem-mem copy(s)
As UDP packets are used, the requesting node uses a time-out to allow for frames lost on the network.
The default UDP port is 14233 or 0x3799, but this can be changed as required.
The socket buffer sizes, and IP Quality of Service, QoS, bits may be set using suitable command line switches. The IP precedence bits, and IP tos bits settings follow RFC1349 which is rather old and has been superseded by the Diffserve Code Points, DSCP, as defined in RFC 2474. Both methods of setting the IP QoS are supported.
To measure the request-response latency between two systems you start udpmon_resp on the remote system with:
./udpmon_resp and run udpmon_req on the local system with, for example:
./udp_req ––d192.168.2.1 –p64 –r64 –l1000
This will make 1000 64 byte requests for 64 byte responses and produce the following output (please ignore the line wrap for the headings): response len bytes; Req len; loop_count; num_bad; time/frame (tod); ave time us; min time; max time; num timeouts;
64; 64; 1000; 0; 58.188; 56.484; 55.28; 80.168; 0
The measurements printed under
time/frame (tod);
use the total time taken for all the requestresponse loops. The measurements printed under ave time us; min time; max time; use the times for individual request-response measurements.
The command
./udpmon_req –d192.168.2.1 –p64 –r64 –l2000 –i8 –e1500 will make a latency scan with 2000 request-responses for each point. It will use 64 byte requests and start by requesting a 64 byte response, when this measurement is finished, it will increment the requested length by 8 bytes and repeat the test until the requested length has reached 1500 bytes. response len bytes; Req len; loop_count; num_bad; time/frame (tod); ave time us; min time; max time; num timeouts;
64; 64; 2000; 0; 127.79; 126.270; 120.77; 1193.952; 0
72; 64; 2000; 0; 127.812; 126.308; 121.49; 144.857; 0
80; 64; 2000; 0; 128.723; 127.209; 122.88; 158.274; 0
88; 64; 2000; 0; 234.72; 233.444; 123.31; 4839.224; 0
…
1496; 64; 2000; 0; 300.382; 298.813; 293.61; 317.982; 0
3

This pair of programs can also provide histograms of the request-response latency with 1 us (or larger) bins. The histograms use the “;” delimiter to facilitate being imported into Excel.
Running udpmon_req
on the local system, with a command containing –H like:
./udpmon_req –d192.168.2.1 –p64 –r64 –l1000 –m30 –b1 -H will produce output similar to: response len bytes; Req len; loop_count; num_bad; time/frame (tod); ave time us; min time; max time; num timeouts;
64; 64; 10000; 0; 45.4189; 45.215; 38.26; 1012.993; 0
Hist 0 Time per req-resp us
counts 9999 mean 44.66 underflows 0 overflows 1
30 ; 0
31 ; 0
32 ; 0
33 ; 0
34 ; 0
35 ; 0
36 ; 0
37 ; 0
38 ; 8
39 ; 21
40 ; 22
41 ; 12
42 ; 16
43 ; 65
44 ; 5313
45 ; 3677
46 ; 409
47 ; 174
48 ; 58
49 ; 70
50 ; 61
51 ; 9
52 ; 0
53 ; 3
54 ; 10
55 ; 33
56 ; 31
57 ; 6
58 ; 1
59 ; 0
60 ; 0
3.1.1 Options for udpmon_resp
-u
-v
-D
-P
-Q
-S
-T
-V
The UDP port number to use for the tests. Enter using base 10, the default is 14233 or 0x3799.
Verbose mode - turn on printout
Run as a daemon, with all standard streams redirected to
/dev/null
Set the IP precedence bits in the response packets. Enter the value required for the “precedence” eg 8 for telnet, using hexadecimal. The program masks the field and places it into the allocated position in the IP header. (This follows RFC1349 and has been superseded by RFC 2474 and the –Q option.)
The DSCP QoS bits to set in the response packets. - Enter the value required using hexadecimal.
Sets the size of the receive & send buffers in bytes.
Set the IP tos bits in the response packets. Enter the value required for the “type of service” using hexadecimal. The program masks the field and places it into the allocated position in the IP header (The value will be shifted left by
1). Bit 0 is set to 0. (This follows RFC1349 and has been superseded by RFC 2474 and the –Q option.)
Print the version number of UDPmon.
4

Control-c terminates the program.
3.1.2 Options for udpmon_req
-b
-d
-e
-i
-l
-m
-p
-q
-r
-v
-u
-w
-H
-P
-Q
-S
-T
The bin width of the latency histogram in us - the default is 1 i.e. 1 μs
The destination IP name or IP address in dot format a.b.c.d.
The end value of the response message length in bytes.
The number of bytes to increment the response message for each test.
The number of times to loop making request-responses.
The minimum value (low limit) for the histogram in μs – the default is 0
The length in bytes of request packet – not including any headers.
Quiet mode - only print the results, no headers.
The size of the response message in bytes – not including any headers. If a scan is requested, this is the length of the packets used in the 1 st test.
Verbose mode - turn on printout
The UDP port number to use for the tests. Enter using base 10, default is 14233 or 0x3799.
The time to wait between successive request-response singleton measurements in us
Print the request-response latency histograms.
Set the IP precedence bits in the request packet. Enter the value required for the “precedence” eg 8 for telnet, using hexadecimal. The program masks the field and places it into the allocated position in the IP header. (This follows RFC1349 and has been superseded by RFC 2474 and the –Q option.)
The DSCP QoS bits to set in the request packet. - Enter the value required using hexadecimal.
Sets the size of the receive & send buffers in bytes.
Set the IP tos bits in the request packet. Enter the value required for the“type of service” using hexadecimal. The program masks the field and places it into the allocated position in the IP header (The value will be shifted left by
1). Bit 0 is set to 0. (This follows RFC1349 and has been superseded by RFC 2474 and the –Q option.)
Print the version number of UDPmon. -V
Control-c displays the number of request-response tests completed, the number requested, the number of timeouts, and the current response length in bytes. [ Take care – the effect on the measurement being made is not well defined.]
Control-z terminates the program.
350
Request was fixed at 64 bytes and the length of the Response was varied with the command:
Figure 3.1 UDP Request-Response latency for 2 PCs directly connected with 100 Mbit Ethernet.
150
100
50
0
0 200 400 600
Message length bytes
1000 1200 1400
PC=PC kernel 2.2.14

Table 3.1 gives an idea of the contributions to the slope, with the 3com interface, each part of the data
transfer should be store and forward, as indicated in the middle column.
Data Path the transfer of the frame over the PCI bus of the sending PC transmission of the packet at 100 Mbit line speed
Inverse Rate
 s/byte
0.0078
0.08 the transfer of the frame over the PCI bus of the receiving PC 0.0078
Total 0.0956
Measured
Driver and application software (both ends)
0.0987
0.0031
Table 3.1 Inverse transfer rates for various data paths
For a 100 MHz PC memory bus (64 bits wide) memory-to-memory copy takes an estimated 0.0025
 s/byte. The figures indicate that just one memory-to-memory copy is involved. (A contribution of
0.005
 s/byte from each end of the link would indicate that each end was doing 2 copies.)
Figure 3.2 shows examples of the histograms of the Request-Response latency measured between two
directly connected PCs. Each bin represents 1 μs. The Full Width at Half Maximum height is 2 to 3 μs, and there are very few points outside the peat to longer times, demonstration the reliability of these timing measurements.
3000
2500
2000
1500
1000
500
0
0 50 100 150
64 bytes PC=PC req-resp
Latency us
200 250 300
5000
4000
3000
2000
1000
0
0
1400 bytes PC=PC req-resp
50 100 150
Latency us
200 250 300
Figure 3.2 Latency Histograms measured between two directly connected PCs. Each bin represents 1 μs.
6

The udpmon_bw_mon
and udpmon_resp programs can measure the following information:

UDP Achievable throughput

Packet loss rate and loss distribution

Packet re-order rate and re-order distributions

Inter-packet jitter

Relative 1-way delay

The CPU load on local & remote nodes (User and kernel mode)

The number of interrupts for the network devices on local & remote nodes
The tests send streams of carefully spaced UDP frames from the Requesting node, to the Responding
node, with the application protocol shown in Figure 4.1. The test starts with the Requesting node
sending a “clear statistics” message to the Responder. This also checks whether a test is currently in progress to this node. On reception of the “OK acknowledgement”, if the –G option has been selected, the Requesting node sends a series of time synchronisation Request-Response messages to determine the relative relation between the two CPU clocks followed by the “start” message. Otherwise the
Requesting node then sends a series of “data” packets separated with a given fixed time interval between the packets. At the end of the test, the Requesting node asks for the statistics collected by the
Responding node. Packet loss for the control messages are handled by suitable time-outs and re-tries in the Requesting node. All packets sent contain a timestamp and a sequence number that increments by 1 for each successive packet. UDPmon can also work in burst mode where groups, or bursts, of spaced packets are sent out at intervals. The socket buffer sizes, IP precedence bits, IP tos bits, or IP DSCP bits may be set using suitable command line switches.
Clear Statistics
OK ACK
Timestamp
Timestamp
Timestamp
●●●
Start
Time Synchronisation
Send data frames at regular intervals
OK done
●●●
●●● Inter frame time
Time to receive
Time to send
Get remote statistics
Send statistics
Figure 4.1 Application Protocol for the Bandwidth and Packet loss measurements.
4.1.1 Bandwidth
The bandwidth of the bottleneck, or the network section that limits the bandwidth in the route between the test nodes, may be determined by measuring the times taken to send and receive a burst of carefully
7

spaced UDP frames. The transmit throughput is found using the amount of data sent and the time taken, and the receive throughput is calculated from the amount of data received and the time from the first data packet to the last packet received. In the terminology of the Network Measurements GGF Working
Group[3], UDPmon measures the Achievable Throughput for UDP. On an unloaded path, this would be an estimation of the Capacity Bandwidth and on a loaded path this would give an estimate of the
Available Bandwidth. The program reports the user data rate and a “wire” rate. The wire rate assumes the link level is Ethernet and takes into account:
IPG
Bytes
12
Ethernet Preamble + start
Ethernet header
Ethernet CRC
IP header
UDP header
Total
8
14
4
10
8
66
4.1.2 Packet loss
Packet loss is measured by the remote or responding node. This checks that the sequence numbers in the packets increase correctly, this also detects out-of-order packets. An out of order event occurs if the current packet received has a sequence number n and the next packet has a sequence number m with m< n. The number of packets seen, the number missed as indicated the sequence number check, and the number out-of-order are reported at the end of each test. Note that out-of-order packets are also counted and reported as lost packets, due to the algorithm, but the percentage loss is calculated form the number of packets received and does not incur this effect.
The responding node also histograms the size of the individual packet losses; and for out-of-order packets it histograms the number of packets that have displaced the particular packet that is out of sequence. These histograms are printed with the –H option.
4.1.3 Jitter
The Responding node also measures the time between successive packets and produces a histogram of these times. As the packets are transmitted at regular intervals, this inter-packet jitter is equivalent to the variation in the 1-way delay of the packets traversing the system, but with a standard deviation √2 larger. This histogram may be requested by the Requesting node at the end of the test with the –H option.
4.1.4 1-way Delay and Packet Loss Distribution
With the -G option, the Responding node can record the arrival times t a
and the relative 1-way delay of each packet that has been sent. To measure the relative 1-way delays, the time difference, and time drift, between the two CPUs are estimated using a set of time-stamped request-response packets sent just prior to the test stream of carefully spaced packets. If a packet fails to arrive, the times for that packet are set to zero allowing packet loss distributions to be made. Ideally, a time series plot of the 1way delay would be flat, but variations in the queuing in the network can cause gradual increases or decreases in the 1-way delay. Queuing in the receiving host due to interrupt coalescence produces a characteristic decreasing saw-tooth with abrupt increases at regular intervals (see the example plot given later). Queuing in the network and end systems may be investigated by comparing the extra time taken to receive the packets. Given that the packets are of fixed length, the slope dN/dt a of the plot of packet number vs arrival time t a
gives a measure of the throughput.
To measure the network characteristics between two systems you start udpmon_resp
on the remote system with:
./udpmon_resp and then run udpmon_bw_mon
on the local system with something like:
8

./udpmon_bw_mon –d192.168.2.1 –p1472 –w20 –l1000
This will send 1000 1472 byte data packets, waiting 20 us between sending each packet.
The program can perform a series of measurements each with the wait time -w incremented by the value set by the
–i
option until the wait time is larger that the end time set by the
–e value.
4.2.1 Options for udpmon_resp
-u
-v
-D
-P
-Q
-S
-T
The UDP port number to use for the tests. Enter using base 10, the default is 14233 or 0x3799.
Verbose mode - turn on printout
Run as a daemon, with all standard streams redirected to
/dev/null
Set the IP precedence bits in the response packets. Enter the value required for the “precedence” eg 8 for telnet, using hexadecimal. The program masks the field and places it into the allocated position in the IP header. (This follows
RFC1349
and has been superseded by RFC 2474 and the –Q option.)
The DSCP QoS bits to set in the response packets. - Enter the value required using hexadecimal.
The size of the receive & send buffers in bytes.
Set the IP tos bits in the response packets. Enter the value required for the “type of service” using hexadecimal. The program masks the field and places it into the allocated position in the IP header (The value will be shifted left by
1). Bit 0 is set to 0. (This follows RFC1349 and has been
-V superseded by RFC 2474 and the –Q option.)
Print the version number of UDPmon.
Control-c terminates the program.
4.2.2 Options for udpmon_bw_mon
-d
-e
-g
The destination IP name or IP address in dot format a.b.c.d.
The end value of the wait time in us.
The (gap) time to wait in us between sending bursts of spaced
UDP packets.
-h Print this help.
-i The number of us to increment the wait time between sending
-l
-n
-p packets.
The number of packets to send.
The number of bursts to send in Burst Mode (-g selected)
The length in bytes of the data packets – not including any
-q
-u
-v
The UDP port number to use for the tests. Enter using base 10.
Verbose mode - turn on printout
-w The time to wait between sending packets in us.
-x Print more information (CPUStats & SNMP data)
-B The bin width of the remote inter-packet time histogram in us
- the default is 1 i.e. 1 μs
-G headers.
Quiet mode - only print the results, no headers.
-t The no. of seconds to run the test (udpmon calculates no. of frames to send )
-H
[number of packets to skip:]The number of packets on which the remote end will return arrival and 1-way timing information.
If given, the histograms made at the receiving node are retrieved and printed out.
-L [number of packets to skip:] The number of LOST packets on
which to return information.
9

-M
-P
-Q
-S
-T
The minimum (low limit) for the remote inter-packet time histogram in μs – the default is 0
Set the IP precedence bits. Enter the value required for the
“precedence” eg 8 for telnet, using hexadecimal. The program masks the field and places it into the allocated position in the IP header. (This follows RFC1349 and has been superseded by
RFC 2474 and the –Q option.)
The DSCP QoS bits to set. - Enter the value required using hexadecimal.
The size of the receive & send buffers in bytes.
Set the IP tos bits. Enter the value required for the
“type of service” using hexadecimal. The program masks the field and places it into the allocated position in the IP header (The value will be shifted left by 1). Bit 0 is set to
0. (This follows RFC1349 and has been superseded by RFC 2474
-V and the –Q option.)
Print the version number of UDPmon.
Control-c displays the number of request-response tests completed, the number requested, the number of timeouts, and the current response length in bytes. [ Take care – the effect on the measurement being made is not well defined.]
Control-z terminates the program.
The elements of the output record are:
Pkt len Size of frame in bytes loop count num ACKs recv
Number of frames sent
Not used num timeout
Time/frame us
Number of timeouts when sending udpmon commands the average time between transmitting data packets, it will be equal to wait_time wait_time when wait_time is greater than the time to send the data.
Time to wait between sending frames in μs
Send time The time the test took
Send data rate Mbit In Mbits/s calculated from the sending time
Number of frames received by udp_resp Num recv num lost num badorder
Number of frames lost
Number of frames received out of order. Note this number is included in num lost
% packet lost calculated from num recv and number of packets sent. % lost
Recv time time/recv pkt
Recv_data_rate
Recv_wire_rate
The time from the first data frame to the last observed
User data rate in Mbits/s
Wire data rate in Mbits/s (see above for definition)
The next parameters come from the histogram of the inter-packet times num_in_hist mean sigma skew kurtosis
Sum of the histogram bin contents
Mean of the histogram
Standard deviation of the histogram (second moment) coefficient of skew (β1) = ∑(x-<x>) 3 /σ 3 measures the asymmetry coefficient of kurtosis (β2) = (∑(x-<x>) 4 /σ 2 ) -3 zero if a perfectly normal distribution median iq25 iq75
Median of the data in the histogram
25 % quartile
75 % quartile
The CPU usage is reported under the headings:
10

Local user cpu %; low-prio cpu %; kernel cpu%; idle cpu%; and
Remote user cpu %; low-prio cpu %; kernel cpu%; idle cpu%;
The usage is measured for each cpu in the system (up to a maximum of 4). The average usage under each mode is reported first “L” and then the usage for each CPU: “L1” “L2” “L3” “L4”. Four CPUs are given even if only some of these exist, so the output for the local node will look like:
L ; 16; 0; 8; 75;;L1 ; 66; 0; 33; 0;;L2 ; 0; 0; 0; 100;;L3 ; 0; 0; 0;
100;;L4 ; 0; 0; 0; 100; and similarly for the remote node:
R; 0; 0; 7; 92;;R1 ; 0; 0; 28; 71;;R2 ; 0; 0; 0; 100;;R3 ; 0; 0; 0; 100;;R4
; 0; 0; 0; 100;
The interrupts are also divided into local and remote:
L int; interrupt device: counts: ; R int; interrupt device: counts:
For each host the number of interrupts that occurred during the test are reported for:
 the system timer
 each network device found on the system.
In this case the local system had two Ethernet devices eth0: and eth2: (both were Intel as it happened) but the remote node has three devices eth0: eth3: and a SysKonnect card.
Local interrupts:
L int;timer: ; 169; eth0: ; 0; eth2: ; 69;
Remote interrupts:
R int;timer: ; 54; eth0: ; 1; SysKonnect: ; 0; eth3: ; 9999;
Local interface statistics:
L if interface:; pktsin; bytesin; pktsout; bytesout;
Local SNMP statistics:
L snmp;
InReceives;
InDiscards;
OutRequests;
OutDiscards;
UDPInDatagrams;
UDPInErrors;
UDPOutDatagrams;
Remote interface statistics:
R if; interface:; pktsin; bytesin; pktsout; bytesout;
Remote SNMP statistics:
R snmp;
InReceives;
InDiscards;
OutRequests;
OutDiscards;
UDPInDatagrams;
UDPInErrors;
11

UDPOutDatagrams;
Remember that the available bandwidth and packet loss may differ if the data flow is from node a->b or from node b->a, depending on the cross traffic or router policies for example.
To measure the network bandwidth available between two systems you start udpmon_resp
on the remote system with:
./udpmon_resp and then run udpmon_bw_mon
on the local system with something like:
./udpmon_bw_mon –d192.168.2.1 –p600 –w20 –l10000
This will send 1000 1472 byte data packets, waiting 20 us between sending each packet; and produce
output similar to that shown in Figure 4.3. (Please ignore the line wrap for the headings). To guide the
eye, the boxes relate the headings recv_data_rate Mbit and recv_wire_rate Mbit with the values obtained. In this case, no packets were lost and a wire rate of 252.49 Mbit/s was achieved. It is worth noting that the wait time between packets (-w) can often determine the throughput observed.
Running udp_bw_mon on the local system, with a command similar to:
./udp_bw_mon –d192.168.2.1 –p1472 –w0 –l10000 –i5 –e30 will make a scan, increasing the wait time us 5 us each time. 1000 packets will be sent for each point,
and it will produce output similar to that shown in Figure 4.3.
12

pkt len; loop_count; num_ACKs recv; num_timeout; Time/frame us; wait_time; Send time; send_data_rate Mbit; num_recv; num_lost; num_badorder;
%lost; Recv time; time/recv pkt; recv_data_rate Mbit; recv_wire_rate Mbit; num_in_hist; mean; sigma; skew; kurtosis; median; iq25; iq75;;
Local user cpu %; low-prio cpu %; kernel cpu%; idle cpu%; ; Remote user cpu %; low-prio cpu %; kernel cpu%; idle cpu%; L int; interrupt device: counts: ; R int; interrupt device: counts:
600; 10000; 0; 0; 21.1042; 20; 211042; 227.443; 10000; 0; 0; 0; 211014; 21.1014; 227.473; 252.495; 9929; 18.0226; 2.20477;
1.90076; 383.802; 18; 18; 18;L ; 16; 0; 8; 75;;L1 ; 66; 0; 33; 0;;L2 ; 0; 0; 0; 100;;L3 ; 0; 0; 0; 100;;L4 ; 0; 0; 0; 100;R; 0; 0; 7; 92;;R1
; 0; 0; 28; 71;;R2 ; 0; 0; 0; 100;;R3 ; 0; 0; 0; 100;;R4 ; 0; 0; 0; 100;L int;timer: ; 169; eth0: ; 0; eth2: ; 69; R int;timer: ; 54; eth0: ;
1; SysKonnect: ; 0; eth3: ; 9999;
Figure 4.3 The output produces by udpmon_bw_mon for a single test. pkt len; loop_count; num_ACKs recv; num_timeout; Time/frame us; wait_time; Send time; send_data_rate Mbit; num_recv; num_lost; num_badorder;
%lost; Recv time; time/recv pkt; recv_data_rate Mbit; recv_wire_rate Mbit; num_in_hist; mean; sigma; skew; kurtosis; median; iq25; iq75;;
Local user cpu %; low-prio cpu %; kernel cpu%; idle cpu%; ; Remote user cpu %; low-prio cpu %; kernel cpu%; idle cpu%; L int; interrupt device: counts: ; R int; interrupt device: counts:
1472; 10000; 0; 0; 12.725; 0; 127250; 925.422; 10000; 0; 0; 0; 127316; 12.7316; 924.943; 966.414; 9999; 11.5035; 4.48676;
6.22189; 1039.17; 11; 10; 12;L ; 4; 0; 8; 87;;L1 ; 0; 0; 8; 91;;L2 ; 0; 0; 0; 100;;L3 ; 16; 0; 25; 58;;L4 ; 0; 0; 0; 100;R; 6; 0; 12; 81;;R1
; 25; 0; 50; 25;;R2 ; 0; 0; 0; 100;;R3 ; 0; 0; 0; 100;;R4 ; 0; 0; 0; 100;L int;timer: ; 257; eth0: ; 0; eth2: ; 128; R int;timer: ; 142; eth0: ; 0; SysKonnect: ; 0; eth3: ; 10002;
1472; 10000; 0; 0; 12.7026; 5; 127026; 927.054; 10000; 0; 0; 0; 127104; 12.7104; 926.485; 968.026; 9999; 11.4928;
6.05673; 2.78982; 656.45; 10; 7; 15;L ; 2; 0; 14; 83;;L1 ; 0; 0; 16; 83;;L2 ; 0; 0; 0; 100;;L3 ; 8; 0; 41; 50;;L4 ; 0; 0; 0; 100;R; 3; 0; 30;
65;;R1 ; 0; 0; 69; 30;;R2 ; 0; 0; 0; 100;;R3 ; 15; 0; 53; 30;;R4 ; 0; 0; 0; 100;L int;timer: ; 14; eth0: ; 0; eth2: ; 128; R int;timer: ;
155; eth0: ; 1; SysKonnect: ; 0; eth3: ; 10001;
1472; 10000; 0; 0; 12.6965; 10; 126965; 927.5; 10000; 0; 0; 0; 126985; 12.6985; 927.354; 968.933; 9999; 11.4611; 6.27605;
2.81499; 683.237; 12; 6; 15;L ; 4; 0; 18; 77;;L1 ; 0; 0; 16; 83;;L2 ; 0; 0; 0; 100;;L3 ; 16; 0; 58; 25;;L4 ; 0; 0; 0; 100;R; 3; 0; 25; 71;;R1
; 0; 0; 38; 61;;R2 ; 0; 0; 0; 100;;R3 ; 15; 0; 61; 23;;R4 ; 0; 0; 0; 100;L int;timer: ; 27; eth0: ; 0; eth2: ; 128; R int;timer: ; 168; eth0:
; 0; SysKonnect: ; 0; eth3: ; 9997;
1472; 10000; 0; 0; 16.651; 15; 166510; 707.225; 10000; 0; 0; 0; 166489; 16.6489; 707.314; 739.028; 9936; 14.1105;
11.2893; 9.98319; 14647.7; 13; 12; 14;L ; 16; 0; 5; 77;;L1 ; 0; 0; 5; 94;;L2 ; 0; 0; 0; 100;;L3 ; 64; 0; 17; 17;;L4 ; 0; 0; 0; 100;R; 0; 0;
19; 80;;R1 ; 0; 0; 29; 70;;R2 ; 0; 0; 0; 100;;R3 ; 0; 0; 47; 52;;R4 ; 0; 0; 0; 100;L int;timer: ; 44; eth0: ; 0; eth2: ; 128; R int;timer: ;
185; eth0: ; 2; SysKonnect: ; 0; eth3: ; 10002;
1472; 10000; 0; 0; 21.5129; 20; 215129; 547.392; 10000; 0; 0; 0; 215101; 21.5101; 547.464; 572.01; 9956; 19.1202; 11.969;
9.97101; 15061.1; 18; 18; 19;L ; 17; 0; 6; 76;;L1 ; 0; 0; 9; 90;;L2 ; 0; 0; 0; 100;;L3 ; 68; 0; 18; 13;;L4 ; 0; 0; 0; 100;R; 3; 0; 11; 85;;R1
; 9; 0; 45; 45;;R2 ; 0; 0; 0; 100;;R3 ; 4; 0; 0; 95;;R4 ; 0; 0; 0; 100;L int;timer: ; 66; eth0: ; 0; eth2: ; 128; R int;timer: ; 207; eth0: ;
2; SysKonnect: ; 0; eth3: ; 10002;
1472; 10000; 0; 0; 26.374; 25; 263740; 446.5; 10000; 0; 0; 0; 263711; 26.3711; 446.549; 466.571; 9961; 24.0642; 11.8091;
9.60774; 13719.5; 23; 23; 24;L ; 20; 0; 6; 73;;L1 ; 0; 0; 11; 88;;L2 ; 0; 0; 0; 100;;L3 ; 80; 0; 15; 3;;L4 ; 0; 0; 0; 100;R; 3; 0; 8; 87;;R1
; 15; 0; 34; 50;;R2 ; 0; 0; 0; 100;;R3 ; 0; 0; 0; 100;;R4 ; 0; 0; 0; 100;L int;timer: ; 92; eth0: ; 0; eth2: ; 128; R int;timer: ; 233; eth0:
; 1; SysKonnect: ; 0; eth3: ; 10002;
1472; 10000; 0; 0; 31.2636; 30; 312636; 376.668; 10000; 0; 0; 0; 312602; 31.2602; 376.709; 393.6; 9949; 28.8048; 10.7498;
9.87042; 12436.7; 28; 28; 29;L ; 18; 0; 4; 76;;L1 ; 0; 0; 0; 100;;L2 ; 0; 0; 0; 100;;L3 ; 74; 0; 19; 6;;L4 ; 0; 0; 0; 100;R; 0; 0; 10; 89;;R1
; 0; 0; 43; 56;;R2 ; 0; 0; 0; 100;;R3 ; 0; 0; 0; 100;;R4 ; 0; 0; 0; 100;L int;timer: ; 124; eth0: ; 0; eth2: ; 129; R int;timer: ; 265; eth0:
; 1; SysKonnect: ; 0; eth3: ; 10002;
Figure 4.3 The output produces by udpmon_bw_mon for a scan of wait times from 0 to 30 µs.
13

4.4.1 100 Mbit PC to PC Laboratory Tests
Ошибка! Источник ссылки не найден.
shows throughput measurements made using UDP frames between two 350 MHz Pentium PCs directly connected with a 100 Mbit Ethernet Link joining the two
3com 3c905 nics. When the time the sender waits between transmitting the frames is greater than the time to physically move the data through the hardware, the log-log plot shows the 1/t behaviour as expected.
120
100
80
100 bytes
200 bytes
400 bytes
600 bytes
800 bytes
1000 bytes
1200 bytes
1400 bytes
60
40
20
0
0 100 200
Send Time/packet us
300 400 500
100
100 bytes
200 bytes
400 bytes
600 bytes
800 bytes
1000 bytes
1200 bytes
1400 bytes
10
1
10 100
Send Time/packet us
1000
Figure 4.4 Plots of the Received wire rate vs time delay between sending packets.
4.4.2 10 Gbit Ethernet PC to PC Laboratory Tests
Figure 4.5 shows the measured UDP Throughput, Packet loss and Kernel load for the sending and
receiving nodes as a function of packet size for two Dual Itanium PCs connected with 10 Gigabit
Ethernet.
These data were collected using the throughput scripts shown in Appendix A.2.
14

100
90
80
70
60
50
40
30
20
10
0
0
100
90
80
70
60
50
40
30
20
10
0
0
100
90
80
70
60
50
40
30
20
10
0
0
6000
5000
4000
3000
2000
1000
0
0
5
5
5
5
Openlab98-99 10GE MTU16114
16080 bytes
16000 bytes
14000 bytes
12000 bytes
10000 bytes
9000 bytes
8000 bytes
7000 bytes
6000 bytes
5000 bytes
4000 bytes
3000 bytes
2000 bytes
1472 bytes
10 15 20
Spacing between frames us
25
Openlab98-99 10GE MTU16114
30 35 40
16080 bytes
16000 bytes
14000 bytes
12000 bytes
10000 bytes
9000 bytes
8000 bytes
7000 bytes
6000 bytes
5000 bytes
4000 bytes
3000 bytes
2000 bytes
1472 bytes
10 15 20
Spacing between frames us
25 30 35
Openlab98-99 10GE MTU16114
40
10 15 20
Spacing between frames us
25 30 35
Openlab98-99 10GE MTU16114
40
10 15 20
Spacing between frames us
25 30 35 40
16080 bytes
16000 bytes
14000 bytes
12000 bytes
10000 bytes
9000 bytes
8000 bytes
7000 bytes
6000 bytes
5000 bytes
4000 bytes
3000 bytes
2000 bytes
1472 bytes
16080 bytes
16000 bytes
14000 bytes
12000 bytes
10000 bytes
9000 bytes
8000 bytes
7000 bytes
6000 bytes
5000 bytes
4000 bytes
3000 bytes
2000 bytes
1472 bytes
Figure 4.5 UDP Throughput, packet loss and Kernel load as a function of packet size
When udpmon_bw_mon
is run with the –q switch, it only produces a line of results similar to:
1004574123 ; 193.60.157.103 ; 130.246.135.152 ; 1400 ; 300 ; 0 ;
0 ; 95.6467 ; 80 ; 28694 ; 117.098 ; 300 ; 0 ; 0 ; 35362
; 117.873 ; 95.0173 ; 99.4966 ; 297 ; 115.367 ; 3.52719 ;
1.30086 ; 584.588 ; 115 ; 115 ; 116
The elements of this record are:
15

time of day sending_ip_address dest_ip_address,
Pkt len loop count
Unix time since the Epoch (1 jan 1970)
Size of frame in bytes
Number of frames sent
Then the other variables are as defined in Section 4.3.
start udpmon_resp on the remote system with:
./udpmon_resp and then run udpmon_bw_mon
on the local system with something like:
./udpmon_bw_mon - d192.168.2.1 -p1472 -w80 -M0 -B2 -H -l100000
This will send 100,000 1472 byte data packets, waiting 80 us between sending each packet; and produce output similar to that below (please ignore the line wrap for the headings and note that some of the histogram output has been cut for clarity).
Note that the histogram limit (-M) and bin size (-B) will need to be adjusted for the given test situation.
pkt len; loop_count; num_ACKs recv; num_timeout; Time/frame us; wait_time; Send time; send_data_rate Mbit; num_recv; num_lost; num_badorder; %lost; Recv time; time/recv pkt; recv_data_rate Mbit; recv_wire_rate Mbit; num_in_hist; mean; sigma; skew; kurtosis; median; iq25; iq75;; Local user cpu %; low-prio cpu %; kernel cpu%; idle cpu%; ; Remote user cpu %; low-prio cpu %; kernel cpu%; idle cpu%; L int; interrupt device: counts: ; R int; interrupt device: counts:
1472; 100000; 0; 0; 79.9982; 80; 7999822; 147.203; 100000; 0; 0; 0;
7999736; 79.9974; 147.205; 153.805; 99999; 78.2084; 2.43316; 7.92377; 4555.46;
78; 78; 78;L ; 25; 0; 13; 61;;L1 ; 0; 0; 52; 47;;L2 ; 0; 0; 0; 100;;L3 ; 100; 0; 0;
0;;L4 ; 0; 0; 0; 100;R; 0; 0; 4; 95;;R1 ; 1; 0; 16; 82;;R2 ; 0; 0; 0; 100;;R3 ; 0; 0;
0; 100;;R4 ; 0; 0; 0; 100;L int;timer: ; 914; eth0: ; 0; eth2: ; 100004; R int;timer:
; 1055; eth0: ; 0; SysKonnect: ; 0; eth3: ; 100008;
Hist 0 Time between frames us
counts 99999 mean 78.21 underflows 0 overflows 1
0 ; 0
…
52 ; 1
54 ; 7
56 ; 6
58 ; 22
60 ; 77
62 ; 29
64 ; 26
66 ; 31
68 ; 52
70 ; 643
72 ; 701
74 ; 3955
76 ; 11088
78 ; 75384
80 ; 3346
82 ; 3539
84 ; 706
86 ; 157
88 ; 35
90 ; 25
92 ; 21
94 ; 35
96 ; 67
98 ; 14
100 ; 3
102 ; 6
104 ; 1
106 ; 0
108 ; 0
16

110 ; 0
…
296 ; 0
298 ; 0
Hist 1 Lost-frame sequence
counts 0 mean 0.00 underflows 0 overflows 0
0 ; 0
1 ; 0
2 ; 0
3 ; 0
4 ; 0
5 ; 0
6 ; 0
7 ; 0
8 ; 0
9 ; 0
Hist 2 Out-of-order
counts 0 mean 0.00 underflows 0 overflows 0
0 ; 0
1 ; 0
2 ; 0
3 ; 0
4 ; 0
5 ; 0
6 ; 0
7 ; 0
8 ; 0
9 ; 0
To investigate packet loss distributions or the variation in 1-way delay of the packets, start udpmon_resp
on the remote system with:
./udpmon_resp and then run udpmon_bw_mon on the local system with something like:
./udpmon_bw_mon -d192.168.2.1 -p1472 -w80 -l10000 -G10000
This will send 10000 1472 byte data packets, waiting 80 us between sending each packet and record the arrival time and 1-way delay for the first 10,000 packets. It will produce output similar to that below
(please ignore the line wrap for the headings).
pkt len; loop_count; num_ACKs recv; num_timeout; Time/frame us; wait_time; Send time; send_data_rate Mbit; num_recv; num_lost; num_badorder; %lost; Recv time; time/recv pkt; recv_data_rate Mbit; recv_wire_rate Mbit; num_in_hist; mean; sigma; skew; kurtosis; median; iq25; iq75;; Local user cpu %; low-prio cpu %; kernel cpu%; idle cpu%; ; Remote user cpu %; low-prio cpu %; kernel cpu%; idle cpu%; L int; interrupt device: counts: ; R int; interrupt device: counts:
1472; 10000; 0; 0; 81.9667; 80; 819667; 143.668; 10000; 0; 0; 0; 819579;
81.9579; 143.684; 150.126; 9997; 80.1252; 1.88674; -5.3207; 2030.89; 80; 80; 80;L
; 22; 0; 2; 75;;L1 ; 89; 0; 10; 0;;L2 ; 0; 0; 0; 100;;L3 ; 0; 0; 0; 100;;L4 ; 0; 0; 0;
100;R; 0; 0; 7; 92;;R1 ; 3; 0; 28; 68;;R2 ; 0; 0; 0; 100;;R3 ; 0; 0; 0; 100;;R4 ; 0;
0; 0; 100;L int;timer: ; 231; eth0: ; 0; eth2: ; 9996; R int;timer: ; 117; eth0: ; 0;
SysKonnect: ; 0; eth3: ; 10003; packet; recv_time; send_time; diff in 0.1us; one_way time us
1; 125179; 121422; 3757; 61.4954
2; 126005; 122223; 3782; 63.994
3; 126794; 123023; 3771; 62.8927
4; 127599; 123823; 3776; 63.3914
5; 128396; 124623; 3773; 63.09
6; 129201; 125423; 3778; 63.5887
7; 129992; 126223; 3769; 62.6873
8; 130800; 127023; 3777; 63.486
9; 131609; 127824; 3785; 64.2846
10; 132431; 128624; 3807; 66.4833
11; 133199; 129424; 3775; 63.282
12; 133994; 130224; 3770; 62.7807
13; 134795; 131025; 3770; 62.7793
17

…
The following figures give some examples of the use of UDPmon to determine the packet loss distributions and the variations in the relative 1-way delay.
Figure 4.6 shows the effect of a 622 Mbit bottleneck on a 1 Gbit Lambda between Amsterdam and
Chicago. The dark blue sections correspond to dropping 1 packet in 3.
Figure 4.7 shows the relative change in 1-way delay time between Manchester and Dwingaloo in the
Netherlands. For the first ~1400 packets, the 1-way delay increases from 8 ms to ~11 ms indicating the formation on queues in the network. After this there is occasional packet loss in the network.
The saw-tooth behaviour of the 1-way delay estimates shown in Figure 4.8 are typical of interfaces
using interrupt coalescence where packets wait in the receiving host until the interrupt is given by the
NIC some time later. Packets transmitted earlier wait for longer giving a longer transit delay. In this case there is no evidence of queuing in the network.
Arrival Time
 s
BW ~500 Mbit/s
Keep 2 packets Drop 1
L2 Buffers full
Figure 4.6 The arrival time of UDP packets as a function of the packet number on the
Amsterdam-Chicago Lambda.
1472 bytes w12 Gnt5-DwMk5 21Oct03
12000
10000
8000
6000
4000
2000
0
0 1000 2000
Packet No.
3000 4000 5000
Figure 4.7 The relative 1-way delay over the production network between Manchester and
Dwingaloo.
18

3800
3700
3600
3500
3400
3300
3200
1000 wait 12 lon3-man1
1200 1400
Packet No.
1600 1800 2000
Figure 4.8 The variation in the relative 1-way delay for two nodes on the MB-NG development network showing the effect of interrupt coalescence. The packets were transmitted with 12 µs spacing.
Appendix A gives listings of some scripts that may be used for making sets of measurements with
UDPmon. The output of each test goes into a text file, which may be read into the Microsoft excel file given on the web site. The tests are grouped according to the Characteristic being observed as shown in the table below.
Network Characteristic
Round trip Latency
UDP Throughput
Jitter large and small packets
File number range
1 - 7
10 - 18
20 – 29 and 30 -39
Packet Loss distribution & Relative 1-way delay 51 – 59
Appendix B gives a listing of the macro in the excel file. The macro allows selection of the input data file and reads it into the currently active sheet. It also changes the name of the sheet to match the file. If the data files are read into the corresponding sheets found in the example excel file, then the plots will be automatically produced.
19

[1] StopWatch_*() routines modified from the CERN Mesh work for ATLAS Experiment at
CERN.
[2] R. E. Hughes-Jones, F. Saka, “Investigation of the Performance of 100Mbit and Gigabit Ethernet
Components Using Raw Ethernet Frames”, ATL-COM-DAQ-2000-014
[3] "A Hierarchy of Network Performance Characteristics for Grid Applications and Services," NM-
WG GGF, http://www-didc.lbl.gov/NMWG/docs/draft-ggf-nmwg-hierarchy-02.pdf
RFC1349 P. Almquist “Type of Service in the Internet Protocol Suite”, Jul 1992
RFC 2474 K. Nichols, S. Blake, F. Baker, D. Black “Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers” Dec 1998
20

FILE=/net_test_vxxx/src-dest_date
DEST=a.b.c.d
PROG=./udpmon_req
$PROG -d$DEST -r64 -i8 -e1500 -l1000 >${FILE}_01.txt
$PROG -d$DEST -r64 -i64 -e16000 -l1000 >${FILE}_02.txt
$PROG -d$DEST -r64 -l1000 -m14550 -b2 -H >${FILE}_03.txt
$PROG -d$DEST -r256 -l1000 -m14550 -b2 -H >${FILE}_04.txt
$PROG -d$DEST -r512 -l1000 -m14700 -b2 -H >${FILE}_05.txt
$PROG -d$DEST -r1024 -l1000 -m14950 -b2 -H >${FILE}_06.txt
$PROG -d$DEST -r1400 -l1000 -m15200 -b2 -H >${FILE}_07.txt
FILE=/net_test_vxxx/src-dest_date
DEST=a.b.c.d
PROG=./udpmon_bw_mon
$PROG -d$DEST -p1400 -w0 -i1 -e40 -l10000 >${FILE}_10.txt
$PROG -d$DEST -p1472 -w0 -i1 -e40 -l10000 >${FILE}_10a.txt
$PROG -d$DEST -p1473 -w0 -i1 -e40 -l10000 >${FILE}_10b.txt
$PROG -d$DEST -p1200 -w0 -i1 -e40 -l10000 >${FILE}_11.txt
$PROG -d$DEST -p1000 -w0 -i1 -e40 -l10000 >${FILE}_12.txt
$PROG -d$DEST -p800 -w0 -i1 -e40 -l10000 >${FILE}_13.txt
$PROG -d$DEST -p600 -w0 -i1 -e40 -l10000 >${FILE}_14.txt
$PROG -d$DEST -p400 -w0 -i1 -e40 -l10000 >${FILE}_15.txt
$PROG -d$DEST -p200 -w0 -i1 -e40 -l10000 >${FILE}_16.txt
$PROG -d$DEST -p100 -w0 -i1 -e40 -l10000 >${FILE}_17.txt
$PROG -d$DEST -p50 -w0 -i1 -e40 -l10000 >${FILE}_18.txt
FILE=/net_test_vxxx/src-dest_date
DEST=a.b.c.d
PROG=./udpmon_bw_mon
$PROG -d$DEST -p1472 -w20 -M0 -B2 -H -l100000 >${FILE}_20.txt
$PROG -d$DEST -p1472 -w30 -M0 -B2 -H -l100000 >${FILE}_21.txt
$PROG -d$DEST -p1472 -w40 -M0 -B2 -H -l100000 >${FILE}_22.txt
$PROG -d$DEST -p1472 -w50 -M0 -B2 -H -l100000 >${FILE}_23.txt
$PROG -d$DEST -p1472 -w60 -M0 -B2 -H -l100000 >${FILE}_24.txt
$PROG -d$DEST -p1472 -w70 -M0 -B2 -H -l100000 >${FILE}_25.txt
$PROG -d$DEST -p1472 -w80 -M0 -B2 -H -l100000 >${FILE}_26.txt
$PROG -d$DEST -p1472 -w100 -M0 -B2 -H -l100000 >${FILE}_27.txt
$PROG -d$DEST -p1472 -w200 -M0 -B2 -H -l100000 >${FILE}_28.txt
$PROG -d$DEST -p1472 -w200 -M0 -B4 -H -l100000 >${FILE}_28a.txt
$PROG -d$DEST -p1472 -w300 -M100 -B2 -H -l100000 >${FILE}_29.txt
$PROG -d$DEST -p100 -w20 -M0 -B2 -H -l100000 >${FILE}_30.txt
$PROG -d$DEST -p100 -w30 -M0 -B2 -H -l100000 >${FILE}_31.txt
$PROG -d$DEST -p100 -w40 -M0 -B2 -H -l100000 >${FILE}_32.txt
$PROG -d$DEST -p100 -w50 -M0 -B2 -H -l100000 >${FILE}_33.txt
$PROG -d$DEST -p100 -w60 -M0 -B2 -H -l100000 >${FILE}_34.txt
$PROG -d$DEST -p100 -w70 -M0 -B2 -H -l100000 >${FILE}_35.txt
$PROG -d$DEST -p100 -w80 -M0 -B2 -H -l100000 >${FILE}_36.txt
$PROG -d$DEST -p100 -w100 -M0 -B2 -H -l100000 >${FILE}_37.txt
$PROG -d$DEST -p100 -w200 -M0 -B2 -H -l100000 >${FILE}_38.txt
$PROG -d$DEST -p100 -w200 -M0 -B4 -H -l100000 >${FILE}_38a.txt
$PROG -d$DEST -p100 -w300 -M100 -B2 -H -l100000 >${FILE}_39.txt
21

FILE=/net_test_vxxx/src-dest_date
DEST=a.b.c.d
PROG=./udpmon_bw_mon
$PROG -d$DEST -p1472 -w11 -l10000 -G10000 >${FILE}_51.txt
$PROG -d$DEST -p1472 -w12 -l10000 -G10000 >${FILE}_52.txt
$PROG -d$DEST -p1472 -w13 -l10000 -G10000 >${FILE}_53.txt
$PROG -d$DEST -p1472 -w14 -l10000 -G10000 >${FILE}_54.txt
$PROG -d$DEST -p1472 -w15 -l10000 -G10000 >${FILE}_55.txt
$PROG -d$DEST -p1472 -w20 -l10000 -G10000 >${FILE}_56.txt
$PROG -d$DEST -p1472 -w100 -l10000 -G10000 >${FILE}_57.txt
$PROG -d$DEST -p1472 -w200 -l10000 -G10000 >${FILE}_58.txt
$PROG -d$DEST -p1472 -w300 -l10000 -G10000 >${FILE}_59.txt
22

The example Microsoft excel file may be used to visualise the data taken with the scripts in Appendix
A Section 7. It contains a macro “Load_net_file()”, given below, that allows selection of the input data
file and reads it into the currently active sheet. It also changes the name of the sheet to match the file
(please not there is a limit of 32 characters of the sheet name).
It the data files are read into the corresponding sheets, then the plots will be automatically produced.
Sub Load_net_file()
'
' Macro4 Macro
' Macro recorded 09-12-2001 by R.Hughes-Jones
'
' Request name of file to open fileToOpen = Application _
.GetOpenFilename("Text Files (*.txt), *.txt")
If fileToOpen <> False Then
' parse filename to make local variables
conn_param = "TEXT;" & fileToOpen
num = InStrRev(fileToOpen, "\") + 1
sheet_name = Mid(fileToOpen, num)
num = InStr(1, sheet_name, ".") - 1
sheet_name = Left(sheet_name, num)
' clear current contents
Cells.Select
Selection.Clear
' Selection.QueryTable.Delete
Range("A1").Select
' name the sheet
ActiveSheet.Name = sheet_name
' input the text data
With ActiveSheet.QueryTables.Add(Connection:= _
conn_param, _
Destination:=Range("A1"))
.Name = "sys_gig_udp_31"
.FieldNames = True
.RowNumbers = False
.FillAdjacentFormulas = False
.PreserveFormatting = True
.RefreshOnFileOpen = False
.RefreshStyle = xlInsertDeleteCells
.SavePassword = False
.SaveData = True
.AdjustColumnWidth = False
.RefreshPeriod = 0
.TextFilePromptOnRefresh = False
.TextFilePlatform = xlWindows
.TextFileStartRow = 1
.TextFileParseType = xlDelimited
.TextFileTextQualifier = xlTextQualifierDoubleQuote
.TextFileConsecutiveDelimiter = False
.TextFileTabDelimiter = True
.TextFileSemicolonDelimiter = True
.TextFileCommaDelimiter = False
.TextFileSpaceDelimiter = False
23

.TextFileColumnDataTypes = Array(1)
.Refresh BackgroundQuery:=False
End With
End If
End Sub
24