UDPmon Tests
Description
Also some experiments were performed with the
UDPmon package written by
R.E. Hughes-Jones, University of Manchester. With this tool a large number
of UDP packets are send to a receiver host where the sequence number and the
arrival time of the packets are registered. This information is send back to the
sender host. To be able to detect the arrival times with sufficient accuracy,
the time information of the oscillator from the Pentium Intel processor is used.
Therefore, this package is only supported at this type of hosts.
Within these tests the following parameters were used:
-
The wait time between two successive packets was 0 s.
-
Trains of in total 5000 packets were send.
-
Packet sizes of 500, 1000, 1200 and 1460 byte were used.
The tests were executed between hosts w06gva-ge-0 and
w06chi-ge-0. As
before, the usage of interface
-ge-1 in Chicago appeared to be preferable afterward due to the default
routing to the Geneva hosts via that interface. Due to the remarkable results
with the packet size of 500 byte, also a second series tests were executed.
The test series will be denoted as series A and B,
respectively.
Results
In the following figures the relative arrival time with respect to the first
packet is displayed as a function of the packet sequence number. For the
series A these data are presented in the
for the direction Geneva ->
Chicago and in the
for the reverse direction. For the series B the
display the results for the direction Geneva ->
Chicago and in the
the data for the reverse direction are given. Lost packets are marked in both
series with zero relative arrival time.
| .I. |
|
Series A: the relative receiving time as
a function of the packet size for the UDP stream in the
direction Geneva -> Chicago.
The packet size was 500 byte. To be able to display
the observed delay, the used Y-axis scale is
different compared with related plots. |
| .II. |
|
Series A: the relative receiving time as
a function of the packet size for the UDP stream in the
direction Geneva -> Chicago.
The packet size was 1000 byte. |
| .III. |
|
Series A: the relative receiving time as
a function of the packet size for the UDP stream in the
direction Geneva -> Chicago.
The packet size was 1200 byte. |
| .IV. |
|
Series A: the relative receiving time as
a function of the packet size for the UDP stream in the
direction Geneva -> Chicago.
The packet size was 1460 byte. |
| .I. |
|
Series A: the relative receiving time as
a function of the packet size for the UDP stream in the
direction Chicago -> Geneva.
The packet size was 500 byte. To be able to display
the observed delay, the used Y-axis scale is
different compared with related plots. |
| .II. |
|
Series A: the relative receiving time as
a function of the packet size for the UDP stream in the
direction Chicago -> Geneva.
The packet size was 1000 byte. |
| .III. |
|
Series A: the relative receiving time as
a function of the packet size for the UDP stream in the
direction Chicago -> Geneva.
The packet size was 1200 byte. |
| .IV. |
|
Series A: the relative receiving time as
a function of the packet size for the UDP stream in the
direction Chicago -> Geneva.
The packet size was 1460 byte. |
| .I. |
|
Series B: the relative receiving time as
a function of the packet size for the UDP stream in the
direction Geneva -> Chicago.
The packet size was 500 byte. |
| .II. |
|
Series B: the relative receiving time as
a function of the packet size for the UDP stream in the
direction Geneva -> Chicago.
The packet size was 1000 byte. |
| .III. |
|
Series B: the relative receiving time as
a function of the packet size for the UDP stream in the
direction Geneva -> Chicago.
The packet size was 1200 byte. |
| .IV. |
|
Series B: the relative receiving time as
a function of the packet size for the UDP stream in the
direction Geneva -> Chicago.
The packet size was 1460 byte. |
| .I. |
|
Series B: the relative receiving time as
a function of the packet size for the UDP stream in the
direction Chicago -> Geneva.
The packet size was 500 byte. |
| .II. |
|
Series B: the relative receiving time as
a function of the packet size for the UDP stream in the
direction Chicago -> Geneva.
The packet size was 1000 byte. |
| .III. |
|
Series B: the relative receiving time as
a function of the packet size for the UDP stream in the
direction Chicago -> Geneva.
The packet size was 1200 byte. |
| .IV. |
|
Series B: the relative receiving time as
a function of the packet size for the UDP stream in the
direction Chicago -> Geneva.
The packet size was 1460 byte. |
In
the following parameters are presented as a function of the test direction and
the packet size, where the following headers are used in this order:
-
Direction (Series)
-
The used test direction and series.
-
Packet size
-
The packet size.
-
Bandwidth
-
The bandwidth without packets lost calculated
.
-
Last recv. seq. nr
-
The sequence number of the last received packet without lost.
-
# Packets lost
-
The number packets lost.
| BW |
= |
(Last_Recv_Seq_Nr *
Packet_Size) / Rel_Time |
|
|
|
with:
| BW |
|
: |
|
The bandwidth without packets lost. |
| Last_Recv_Seq_Nr |
|
: |
|
The sequence number of the last received packet without
lost. |
| Packet_Size |
|
: |
|
The packet size. |
| Rel_Time |
|
: |
|
The time difference with the first packet
(Seq. nr: 0). |
Direction
(Series)
|
Packet size
[byte]
|
Bandwidth
[Mbit/s]
|
Last recv.
seq. nr
|
# Packets
lost
|
Geneva -> Chicago
(A)
|
500 |
144 |
102 |
905 |
| 1000 |
635 |
222 |
1381 |
| 1200 |
946 |
4999 |
0 |
| 1460 |
955 |
4999 |
0 |
Chicago -> Geneva
(A)
|
500 |
462 |
1729 |
1449 |
| 1000 |
752 |
485 |
977 |
| 1200 |
946 |
4999 |
0 |
| 1460 |
955 |
4999 |
0 |
Geneva -> Chicago
(B)
|
500 |
454 |
3123 |
79 |
| 1000 |
676 |
283 |
1642 |
| 1200 |
946 |
4999 |
0 |
| 1460 |
955 |
4999 |
0 |
Chicago -> Geneva
(B)
|
500 |
436 |
765 |
888 |
| 1000 |
710 |
368 |
713 |
| 1200 |
946 |
4999 |
0 |
| 1460 |
955 |
4999 |
0 |
| . |
|
The bandwidth calculated
,
the last received packet without lost, and the
# packets lost given as function of the packet
size and the test direction. |
Conclusions
From
and
the following conclusions can be drawn:
-
With the packet sizes of 500 and 1000 byte there are much more package
lost in the DataTAG results compared with the Netherlight results. The
faster DataTAG hosts might lead to more congestion and therefore packets
loss in the network equipment.
-
With the packet sizes of 1200 and 1460 byte the bottleneck is the
1 Gbyte connection with the host.
-
No asymmetry in both directions has been observed.
-
The observed delay with a packet size of 500 byte in
series A is not very well understood and should be subject of
further investigation.