This site has been archived. For information on the GN Project’s eduPERT initiative please visit https://archive.geant.org/projects/gn3/geant/services/edupert/Pages/Home.html

Thrulay

Thrulay is a measurement tool suggested by Stanislav Shalunov. It performs TCP throughput ("bandwidth") tests similar to many other tools, but at the same time measures round-trip time.

Basic Operation

Thrulay consists of a client and a server. The server listens on a TCP port, 5003 by default. The client opens a connection to the server, checks whether the protocol versions are compatible, and issues a "session proposal" to request a measurement. The proposal can be for a TCP or UDP session. After the server agrees to the session proposal, the client sends measurement data.

TCP Measurements

For TCP, the client can request specific values for the TCP window size and the block size used for measurement. The measurement data consists of blocks (for TCP) or datagrams (for UDP), which include timestamps. The server echoes these timestamps back to the sender, which can then compute the round-trip time for each block. The default block size is 8 KiB. For high-bandwidth paths, it can be useful to specify a larger value (such as 64 KiB) in order to reduce CPU overhead. The default value is kept low so that RTT measurements are still somewhat realistic for lower-bandwidth paths, e.g. paths including ADSL links.

UDP Measurements

For UDP, the client specifies client port number, packet rate, packet size, and the number of packets to be sent. In contrast to TCP measurements, the server doesn't echo back anything until the test is done. The UDP test measures one-way delay instead of round-trip time.

Variants

thrulay

Stanislav Shalunov's original implementation. It was initially called i2perf , but renamed to thrulay to avoid confusion with iperf .

thrulay-ng

Bernhard Lutzmann's Google "summer of code" project included the following improvements as goals:

  • TCP test: multi-stream support, statistics (throughput, minimum/average/maximum RTT)
  • UDP test: send fine-grained Poisson test stream, statistics (quantiles, duplication, packet loss, reordering)
  • Portable: runs on Linux, BSD (FreeBSD, OpenBSD, NetBSD), Mac OS X and Solaris
  • Client authentication based on netmasks
  • Uses faster gettimeofday() implementations if available
  • IPv6 support

thrulay-hd

Huadong Liu developed this in another Google "summer of code" project. It includes the following enhancements:

  • Multiple TCP and UDP streams using a event based implementation
  • API for programmatic execution of thrulay tests;
  • Platform independent (currently running on Linux, Solaris, FreeBSD and Mac OS X);
  • Online calculation of 0/50/95th quantile of one way delay and number of loss periods;
  • IPv6 support and client address based authentication.

Examples (=trulay-hd=)

The following shows a few examples of thrulay in action. We use the thrulay-hd variant.

Server side

The server must be started before any tests are run. By default, it will put itself in the background and will continue to accept test requests from clients indefinitely.

: leinen@atitlan[thrulay-hd-0.6.4]; ./src/thrulayd

TCP Measurement

This example shows a thrulay-hd TCP test run between two hosts with Gigabit Ethernet connections. The base RTT as measured by (IPv6) ping is 4.3 milliseconds. The server ( atitlan=) is a GNU/Linux system, the client (=diotima=) r uns Solaris Express "Nevada" build 70. Note that IPv6 is being used, because the specified destination host =atitlan has both IPv4 and IPv6 addresses registered in the DNS. Results are displayed in one-second intervals throughout the duration of the test. We use the default duration of 60 seconds, but have shortened the output somewhat for readability.

Client side

: leinen@diotima[thrulay-hd-0.6.4]; ./src/thrulay atitlan
IPV6_MTU is not supported.
# local window = 4194304B; remote window = 8388608B
# block size = 8192B
# Path MTU = 1500B, MSS = 1428B, matchs Ethernet
# test duration = 60s; reporting interval = 1s
SID     begin,s  end,s  Mb/s     RTT,ms: min   avg   max
(0)     0.000    1.003  593.094    6.152   36.146  115.325
(0)     1.003    2.002  661.166    6.124   32.846   68.111
(0)     2.002    3.003  654.717    6.328   32.133   71.383
(0)     3.003    4.004  659.903    6.351   32.325   67.431
(0)     4.004    5.000  664.019    6.508   32.379   65.492
(0)     5.000    6.000  656.880    6.675   32.878   65.304
(0)     6.000    7.000  650.046    6.457   34.251   64.782
(0)     7.000    8.001  668.531    6.663   33.943   67.761
(0)     8.001    9.002  663.681    6.307   32.474   69.066
(0)     9.002   10.000  665.321    6.202   32.306   59.894
(0)    10.000   11.000  666.308    6.452   31.681   65.070
[...]
(0)    57.000   58.001  664.442    6.224   32.403   64.556
(0)    58.001   59.000  667.115    6.510   33.169   64.047
(0)    59.000   60.002  660.754    5.879   32.336   63.744
(0)#    0.000   60.002  662.297    5.602   32.548  115.325

UDP Measurement

Client side

Here is a ten-second UDP test run at a rate of 900 Mbit/s between the same pair of hosts. The Solaris host diotima sends to the GNU/Linux host atitlan . As one can see, there is no loss or reordering. We see that the measured delays are negative, which shows that those are indeed one-way delay measurements - imperfect clock synchronization combined with a short network path (about 340km) conspire to make the computed delays negative. In contrast to the TCP test, no results are shown until after the complete test stream has been sent.

: leinen@diotima[thrulay-hd-0.6.4]; ./src/thrulay -t10 -u900M atitlan
# client buffer size = 1882384B
# packet size = 1500B
# (0) remote UDP port = 5003
Server UDP buffer size: 8388608B
Packets client proposed to send: 750000
Packets client sent: 750000
Packets server received: 750000
Packets duplicated: 0
0th quantile of delay (ignoring clock offset): -4.070ms
50th quantile of delay (ignoring clock offset): -4.005ms
95th quantile of delay (ignoring clock offset): -0.046ms
Total packet loss: 0
Total loss period: 0
Packet loss rate: 0.000000%
no reordering

References

– Main.SimonLeinen - 28 Sep 2007

  • No labels