BitTorrent and stream tests in 0.3.6
Neubot 0.3.6 contains two new client-server transmission tests, bittorrent and stream. The former measures the download speed emulating the BitTorrent protocol. The latter measures the download speed receiving a random stream of bytes.
In this blog we describe briefly both tests and we report on what still needs to be done to get them out of "beta".
To invoke the bittorrent test just run the neubot bittorrent command from your favourite shell. This command connects to a remote server using one TCP connection. The connecting Neubot (i.e. the client) then pipelines a certain amount of piece requests. The server queues and sends back a piece for each incoming request, and the client, in turn, sends another request for each piece it receives. After ten seconds the test stops and the client exits, returning the control to the shell. The following picture displays the result of the this test, run from my laptop.
The first column contains round-trip time (RTT) measurements. There is just one measurement because this test estimates the RTT only once, on connect() -- i.e. that was the time required to connect() to the remote host. The row that contains the RTT sample is printed immediately after the connection is established. In this case, after 69.4 milliseconds. This is the Internet equivalent of the "distance" between my laptop and the server just before starting the test.
The second column contains the download speed. Each second Neubot prints the average download speed accounting for all the bytes received during that second. Of course there is not a download speed sample in the first row because that line is printed immediately. Note that the download speed rises from 1.0 Mbit/s to 6.7 Mbit/s during the first second, then reaches the equilibrium, and there are just small oscillations, because the path seems not to be congested. (With more congestion you would have seen more extensive oscillations and possibly a lower peak speed.)
The third column contains the upload speed and is handled similarly to the second one. In this case the upload column is less interesting because the test is not uploading stuff to the server. However, the speed is nonzero because the client uses the upload path to send more piece requests to the server. This is needed because the server sends a piece to the client when it receives a piece request only.
To invoke the stream test just run the neubot stream command from your favourite shell. This command connects to a remote server using one TCP connection. The server then sends as much random data as possible to the connecting Neubot (i.e. the client), and the client discards such data. After ten seconds the test stops and the client exits, returning the control to the shell. The following picture displays the result of the this test, run from my laptop.
The columns in this screenshot are the same as the ones in the BitTorrent picture above. Some notable differences are that, this time:
- the time required to connect() to the server was a bit lower than before (this is quite normal);
- it takes some more seconds for the download speed to grow to the peak speed (this might be because the bittorrent test use an alternate socket buffer management policy);
- the upload speed is always zero because in this test the client does not need to send small requests to the server.
At the moment, these tests probe the downstream path only, and we need to enhance them to probe the upstream path as well. Also, we have to rework the implementation so that Neubot can perform these tests automatically and save the results on our remote servers. Finally, we must modify the tests to use the same socket buffer management policy: They were implemented using different approaches but that makes it a bit difficult to compare the results.