MTR - The Fastest Frog in the Pond
Sometimes when sprending a file, the upload seems to go on forever. This article shows how a Sprend user can pinpoint bottlenecks using the My Traceroute (MTR) tool. Here are the installation instructions for Mac, Windows and Linux.
All comments made by a frog are underlined in frog green.
MTR - The Fastest Frog in the Pond
Chopping and hopping
Let’s start with a bit of background: wouldn’t you like to know how a file is transferred across the Internet from your computer to sprend.com? You bet I would
First, go to the sprend.com website. I am already having fun!
Select one or more files from your computer.
Click on the Send button.
The Sprend web application will now read the first megabyte of data from your computer’s hard drive. On a Mac, the hard drive is usually named Macintosh HD, and it is not a hard drive but rather a set of interconnected memory chips. And fish?
Now the 1 MB chunk of data is sent to sprend.com. The operating system, e.g. macOS or Windows, further divides this chunk into small IP packets, normally 1.5 KB in size, each containing a slice of file data and the destination address.
Each IP packet is transferred to Sprend’s server computer through several routers. The packet hops from router to router, finally landing at sprend.com. As long as there are hops, there is pilsener
All packets arriving at sprend.com are reassembled into a file by the Debian Linux operating system and forwarded to the Sprend server application. Which holds the secret sauce
Sprend saves the file onto the server’s hard drive. And guess what? Sprend uses old-fashioned magnetic hard drives to store data! Hard drives can be larger than SSD disks and are cheaper per gigabyte of storage space. Good ol’ Sprend
The very busy frog
I have a friend, MTR is his name, and he is a frog. He is the quickest hopper in the pond. Yup that's me. The pond is so big that it encompasses the entire planet, and it is full of water lily pads (routers) to jump on. MTR loves to help out with understanding why a transfer is slow. MTR pretends to carry packets across the Internet towards the destination sprend.com. Please, MTR, let us know how you do it!
I start by taking one hop towards sprend.com, and then immediately I jump back to the start
I take two hops, turn around, and return to the start
I keep repeating that procedure until I've reached sprend.com and returned. There could be 10-20 hops before the destination is reached
For every lap, I note down the time in milliseconds
The procedure is typically repeated 600 times, which takes 10 minutes and allows calculation of the average time for each step. Why go just part of the route and return? Because this is how we can find out which router is causing trouble, if any. Let’s learn more by checking out two examples.
From Stockholm to Stockholm!
Sprend's office is at The Park Coworking in Stockholm. Frogholm? Sprend’s server is also located in Stockholm, in the GleSYS data centre. Many of our users are also based in Stockholm, which is good news for them, as their files will need to travel a shorter distance. The table below shows the results of running MTR for 10 minutes from my MacBook, targeting the sprend.com production server.
MTR
Start: 2024-03-13 16:02 (Swedish time)
No of cycles: 600 (10 minutes)
From: Sprend offices in Stockholm
To: sprend.com production server in Stockholm
| Hop | Address | Organisation | Packet Loss % | Average time, there and back |
|---|---|---|---|---|
| 0 | My MacBook Pro | Sprend | — | — |
| 1 | 172.16.0.1 | The Park | 0 % | 4 ms |
| 2 | gw162.a137.corp.bahnhof.se | Bahnhof | 0 % | 16 ms |
| 3 | sto-ste-dr2.sto-ste-dr3.bahnhof.net | Bahnhof | 0 % | 9 ms |
| 4 | sto-ste-dr3.sto-cr3.bahnhof.net | Bahnhof | 1 % | 5 ms |
| 5 | sto-cr1.sto4-er1.as8473.net | Bahnhof | 28 % | 6 ms |
| 6 | be-13.cr2.sto2.se.portlane.net | GleSYS | 1 % | 5 ms |
| 7 | be-2.pe3.sto1.se.portlane.net | GleSYS | 0 % | 6 ms |
| 8 | eth-51-2.le1.sto1.se.portlane.net | GleSYS | 0 % | 5 ms |
| 9 | eth-51-2.le3.sto1.se.portlane.net | GleSYS | 1 % | 6 ms |
| 10 | www.sprend.com | Sprend | — | — |
The IP packets have to take 10 hops to reach sprend.com. The first part goes through the routers of the Internet Service Provider Bahnhof, and the second part through the backbone of GleSYS AB, finally landing in the data centre where the sprend.com server is located.
In the Packet Loss % column, we can see that very few packets are lost en route to sprend.com. The only unexpected value is in hop 5, where we get 28 %. If that router drops so many packets, how come the final loss is only 1% in hop 10? This may be because the router, sto-cr1.sto4-er1.as8473.net, is configured to prioritise real packets. MTR sends a kind of testing packets that the router can choose to ignore. The conclusion is that this is not a problem.
In the rightmost column, we can see the average time for the packets to travel from the start to each hop and back. The average is measured on 600 attempts. We can see that the packets travel very quickly from start to finish and back: only 6 ms is needed for the full round trip. In hop number 2, there is a slightly longer round-trip time, 16 ms. This, however, is not a problem, since the delay is absent in subsequent hops.
From Singapore to Stockholm
In this MTR run, I wanted to try a longer distance with more hops, so I logged into a DigitalOcean-provided computer in Singapore. The target computer is still the sprend.com server in Stockholm.
MTR
Start: 2024-03-13 16:02 (Swedish time)
No of cycles: 600 (10 minutes)
From: DigitalOcean data centre in Singapore
To: sprend.com production server in Stockholm
| Hop | Address | Organisation | Location | Packet Loss % | Average time, there and back |
|---|---|---|---|---|---|
| 0 | A Linux virtual server | Digital Ocean | Singapore | — | — |
| 1 | Not reported | Digital Ocean | Singapore | 100 % | — |
| 2 | 10.76.195.152 | Digital Ocean | Singapore | 0 % | 1 ms |
| 3 | 143.198.252.6 | Digital Ocean | Singapore | 0 % | 0 ms |
| 4 | 143.244.192.176 | Digital Ocean | Singapore | 0 % | 0 ms |
| 5 | 143.244.224.230 | Digital Ocean | Singapore | 0 % | 1 ms |
| 6 | 143.244.224.207 | Digital Ocean | Singapore | 0 % | 0 ms |
| 7 | snge-b5-link.ip.twelve99.net | Arelion | Singapore | 88 % | 96 ms |
| 8 | snge-b7-link.ip.twelve99.net | Arelion | Singapore | 60 % | 1 ms |
| 9 | mei-b5-link.ip.twelve99.net | Arelion | Marseille | 0 % | 151 ms |
| 10 | ffm-bb1-link.ip.twelve99.net | Arelion | Frankfurt | 0 % | 157 ms |
| 11 | ffm-b18-link.ip.twelve99.net | Arelion | Frogfurt | 53 % | 155 ms |
| 12 | glesys-ic-384552.ip.twelve99-cust.net | Arelion | ? | 0 % | 233 ms |
| 13 | be-13.cr2.cop1.dk.portlane.net | GleSYS | Copenhagen | 0 % | 187 ms |
| 14 | be-5.cr1.mal4.se.portlane.net | GleSYS | Malmö | 3 % | 165 ms |
| 15 | be-5.cr2.sto1.se.portlane.net | GleSYS | Stockholm | 3 % | 234 ms |
| 16 | be-1.pe4.sto1.se.portlane.net | GleSYS | Stockholm | 4 % | 256 ms |
| 17 | vl-3003.z3-26-05.sto1.se.portlane.net | GleSYS | Stockholm | 0 % | 250 ms |
| 18 | www.sprend.com | Sprend | Stockholm | 1 % | 250 ms |
As expected, there are more hops for our fantastic frog to take, 8 more of them. We start with the DigitalOcean infrastructure, hop over to international backbone provider Arelion, and end, as before, in the GleSYS network.
As in the previous example, the packet loss in hops 1, 7, 8, and 11 can be safely ignored. Those routers don’t really care about the test packets MTR sends. The main point is that only 1% has been lost in the last hop.
The Average Time column is more interesting now that our famous frog is travelling to the other end of the pond. The interesting hop is number 9, with an average round-trip time of 151 ms. In subsequent hops, this number never decreases, indicating that this delay will be present when real files are sent. It also makes sense since in hop 9 the packets are travelling from Singapore to Marseille, a rather long geographic distance.
The next delay that accumulates towards sprend.com seems to be added in hop 15, with a round-trip time of 234 ms. The name of the router at hop no 14 indicates it is located in Malmö (be-5.cr1.mal4.se.portlane.net), and no 15 in Stockholm (be-5.cr2.sto1.se.portlane.net). That distance could possibly explain the longer time needed.
Conclusions
There are many more tests that we could (should) run, from different parts of the world, highlighting different kinds of problems. We should also run the tests in the opposite direction since the return path may differ.
As a Sprend user, you may download MTR and run it against sprend.com. Please also contact us so that we can run MTR in the opposite direction. Together, we might be able to find out why your transfer is slow. Happy hopping, happy sprending!
Original publishing date: 2024-03-20