Most network monitoring tools provide information on how much data was transported by core networks. Other tools exist to measure round trip times and packet losses. Many of those tools do not visualise what an end user really is interested in: the goodput. Goodput is defined as actual useful data transfer from/to the user application. Packet losses and retransmissions are of no interest for the goodput, although the round trip time, or, more important, task completion time, in the applications may increase. Reports from core networks may show high volume data transfers but these numbers are useless if it is not known what part of that is retransmission.
The at the Utrecht University developed network monitoring package named
is capable of visualising end user Quality of Service aspects from the
(research) network. Currently measurements are performed for several
including the European research network, a distributed computer cluster
DAS, scattered over five
universities in the Netherlands and the user sites of the collaboratory
experiment Dynacore (RE
4005). In the Dynacore project the goal was to see if the current backbones
can support the network requirements of a collaboratory, in the Distributed
ASCI Supercomputer project the goal was to compare the QoS obtained from
an ATM based MBS service to the "normal" over provisioned Internet service.
In Dynacore we found that the actual available network resources were
to exploit any form of collaboratory. The situation has improved a lot
recently. In the DAS project we can prove that the use of a QoS service
is very beneficial for the distributed computing application.
At each host i ( ) the tests, listed below, are performed. The tests are executed by generally available and commonly used programs.
. The control host starts the measurements at all hosts i with remote shells. Host i executes the measurements to the hosts j. The results are send back by host i to the control host.
The maximum rate at which none of the offered frames are dropped by the device.
The Perl script at the control host collects the results of the measurements for each host i (see ) and stores the results in ZIP compressed data files. The ZIP compression is used to reduce disk space and download time (see below).
The presentation of these results is Web based: a Java Applet is used to load the data from the files into the memory of the browser. Please note that the functionality to read (ZIP compressed) data files from a Web browser is a Java feature.
The following data files are available to be viewed via the Web:
|EUCS||Computing Services, The University of Edinburgh||Edinburgh, United Kingdom||qasbah.ucs.ed.ac.uk
|Red Hat Linux 6.0
|MCC||Manchester Computing, University of Manchester||Manchester, United Kingdom||nessie.mcc.ac.uk
|ULB||Université Libre de Bruxelles||Bruxelles, Belgium||sun7.iihe.ac.be
|Sun Solaris 2.6
|SARA||Academic Computing Services Amsterdam||Amsterdam, Netherlands||188.8.131.52
|Red Hat Linux 5.1
|UU-36||Institute of Computational
|Utrecht, Netherlands||hst3736.phys.uu.nl (SURFnet)||Sun Solaris 7
|ZAM||Central Institute for Applied
|Sun Solaris 7
(CERN via SWITCH / TEN-155)
|Sun Solaris 2.6
|CIC||Computing and Information Centre, Czech Technical University in Prague||Prague, Czech Republic||nms.cvut.cz
|Sun Solaris 2.5
In the topology map of the part of the TEN-155 network is given which connects the used NRN's and the participating sites. Note that this map does not give a correct geographical representation of the displayed locations. See for more information also the topology map of the TEN-155 network from DANTE.
. Description of the sites participating in the European monitor. The names, displayed with the header "Title", are corresponding with the host titles used in the HTML tables from the network performance monitor.
Please note that the thruput and round trip measurements are not executed for the full matrix which is formed when all sites are pairwise connected: only tests are performed at connections between sites which are selected such that:
. Topology map of the part of the TEN-155 network which connects the used NRN's and the participating sites.
The results are presented in the form of plots from thruput measurements between sites, specified in , using the same TEN-155 connection. The plots for the connections listed below are displayed. Please note that only a selection of the TEN-155 selections are listed here. The connections via / to Paris, Bruxelles and Prague are excluded here. Only the busiest connections with the most redundant host information is displayed here. However, all connections will be evaluated in the final report.
. Average workday thruput values for the connection London <=> Amsterdam.
. Average weekend thruput values for the connection London <=> Amsterdam.
. Average workday thruput values for the connection Amsterdam <=> Geneva.
. Average weekend thruput values for the connection Amsterdam <=> Geneva.
. Average workday thruput values for the connection Amsterdam <=> Frankfurt.
. Average weekend thruput values for the connection Amsterdam <=> Frankfurt.
. Average workday thruput values for the connection Frankfurt <=> Geneva.
. Average weekend thruput values for the connection Frankfurt <=> Geneva.
The following conclusions can be given:
From there follows that the round trip times are in reasonable correspondence with the geographical distance. However, some connection show now and then large delays. The explanation may be that a non-default route is followed. Smaller delays may be caused by waiting times in the NRN routers.
. The minimum round trip values for the connections to / from UU-36. Each sixth row from the original table is displayed here.