Using the Janet Network performance test facilities

iperf

The commonly used iperf tool is generally used to test available throughput from a client to a server, or from the server back to the client. The test defaults to using TCP. 

There are two versions of iperf, developed and maintained separately, and we support both.  

iperf2

This runs on its default port 5001. The client ships with many OSes, but the most recent version is available from sourceforge.net.

iperf3

This also runs on its default port 5201. You can download the client for a wide variety of OSes including mobile platforms. Download at iperf.fr.

To test against the Slough server you can test with either iperf2 or iperf3 to the server name iperf-slough-10g.perf.ja.net.

Whether a single stream test can fill a link depends on the operating system, the link capacity, the server hardware and the server (TCP) tuning. For most Linux cases, it should be possible to drive 10Gbit/s with a single iperf stream. If not, it is also possible to run multi-stream tests which should achieve greater performance, particularly if there is some packet loss on the path.  

We support iperf testing at rates over 10Gbit/s and up to 100Gbit/s at our London PoP, but this is currently only available on request to netperf@jisc.ac.uk. In this case, using multi-stream tests will likely be required to fill the higher capacity path. 

Ethr

Ethr is an alternative network performance test tool, written in Go. We provide an endpoint at our Slough PoP running at ethr-slough-10g.perf.ja.net. 

Distributions of ethr are available on GitHub, where the README provides instructions for Windows, Linux and macOS. Find out specific CentOS instalaltion information.

perfSONAR

An iperf or Ethr test only tests performance at a specific moment in time, just as a ping or traceroute test only shows you the current round-trip time, loss or path.  

In contrast, perfSONAR provides a means to measure a range of network characteristics over time, to record them, and to use that history of measurements to better diagnose or troubleshoot performance issues. By default, perfSONAR runs latency, loss and path tests continuously and throughput tests every 6 hours. 

The perfSONAR software is open source and runs on a variety of Linux platforms. A new major version, 5.0, was released in April 2023. Read documentation about perfSONAR.

The software is usually run on a dedicated physical server, but you can use a VM or container.

View guidance on:

• Docker information
• perfSONAR hardware guidance

To minimise interference between tests you should use two separate network interfaces for the server, one for throughput tests, one for latency/loss tests. 

There are multiple perfSONAR components that can be installed. The simplest is to install the tools and testpoint packages, such that your server can run tests and report them to another server that archives the results into OpenSearch. The ‘core’ package will additionally allow local archiving, while the full toolkit install will give all functionality. Read guidance on perfSONAR installation options.  

perfSONAR servers running the toolkit will need a certificate. We recommend you use a certificate that is signed by an authority trusted by browsers, such as certificates issued by the Jisc certificate service or Let’s Encrypt, rather than self-signed. 

Once installed, you can configure persistent throughput and latency/loss tests to our Jisc perfSONAR servers. You should run throughput tests to the throughput interface, and latency tests to the latency interface.  

Slough DC, running at up to 10Gbit/s: 

• Throughput interface - ps-slough-bw.perf.ja.net
• Latency interface - ps-slough-lat.perf.ja.net

London PoP, running at up to 100Gbit/s: 

• Throughput interface - ps-london-bw.perf.ja.net
• Latency interface - ps-london-lat.perf.ja.net

perfSONAR uses a tool called pscheduler to ensure that throughput tests do not overlap or contend with other tests, so you should have the full capacity of the link available for your measurements. 

You can also run third-party tests with pscheduler, between two remote perfSONAR servers, if they are configured (via the limits file) to be open, for example: 

$ pscheduler task  throughput --source HOST1  --dest HOST2 

While tests can be configured to run persistently to/from any given perfSONAR server, it is also possible to create a ‘mesh’ of servers for a community where each tests against the other. One example is the UK World Large Hadron Collider Computing Grid (WLCG) community, GridPP, which has a number of meshes for IPv4 and IPv6 testing. Another is the WLCG 100G server mesh. Jisc can assist with mesh configurations if required. Other servers can be found via the perfSONAR lookup service. 

Data Transfer Node (DTN) tests

Jisc hosts data transfer nodes (DTNs) for application-oriented testing. We can install and support any specific data transfer tools on request.  

Currently our Slough DC has a Globus endpoint, running at dtn-slough-10g.perf.ja.net, which is connected at 10Gbit/s.

The basic Globus transfer tools can be run without a Globus licence/subscription. 

A variety of files is available for testing Globus with globus-url-copy: 1M.dat, 2M.dat, 10M.dat, 50M.dat, 1G.dat, 10G.dat, 20G.dat, 100G.dat, 1000G.dat 

You can copy to /dev/null or to the file system, for example, copying a 10GB file to /dev/null: 

$ globus-url-copy -vb ftp://dtn-slough-10g.perf.ja.net:2811/space00/10G.dat /dev/null 

There is also a directory with 100 x 1GB files for more sustained testing:  

$ globus-url-copy -r -vb ftp://dtn-slough-10g.perf.ja.net:2811/space00/small/ file:///tmp/ 

We also have a 100G DTN at our London PoP. Please email netperf@jisc.ac.uk if you wish to test against this. 

RIPE Atlas anchor

The RIPE Atlas project has grown to over 10,000 measurement devices worldwide, and now supports both physical (small form factor USB/Ethernet) and virtual clients. These can be used to run lightweight tests such as latency, loss, HTTP and DNS between clients and anchors. 

Jisc runs a (physical) anchor at our Slough DC which has a web interface available at RIPE Atlas. At the time of writing there are some 6,000 tests being run against the anchor. 

Tools in development

We are currently looking to deploy an HTTP-based ‘speedtest’ service, most likely using the open source librespeed package. There are other implementations available which we are also testing. 

Such speedtests aren’t necessarily as accurate as the ones described above, but these are the types of tests that will most likely be run by users served by the Janet network, and in their home networks, because they are trivially easy to run from a browser without installing any local software. By providing a familiar tool we can also include pointers at the test pages towards the more advanced tools, and information describing the limitations of ‘speedtest’ servers. 

We are also following the latest developments in the IP Performance Measurement working group at the Internet Engineering Task Force (IETF) on a new ‘responsiveness’ test. The idea of the test is to measure how many responses per second a server can reply with, which is an indication of the potential buffering delays or ‘buffer bloat’ in a network path.