Plans & Prices About us Contact Sign Up Log in

MTR - The Fastest Frog in the Pond

Sometimes when sprending a file, the upload seems to go on forever. This article shows how a user of Sprend can pinpoint the bottlenecks using the My Traceroute (MTR) tool. Here are the installation instructions for Mac, Windows and Linux. All comments made by a frog is marked in frog green.

Chopping and hopping

To start with some background, wouldn’t you like to know how a file is transferred across the Internet from your computer to You bet I would

  1. First, go to the website. I am already having fun!
  2. Select one or more files from your computer.
  3. Click on the black button.
  4. The Sprend web application will now read one 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?
  5. Now the 1 MB chunk of data is sent to The operating system, macOS, 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.
  6. Each IP packet is transferred to Sprend’s server computer through several routers. The packet hops from router to router, to finally land at As long as there are hops, there is pilsener
  7. Every incoming packet on is reassembled into a file by the Debian Linux operating system, and forwarded to the Sprend server application. Which holds the secret sauce
  8. 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 it encompasses the entire planet, and the pond is full of water lily pads (routers) to jump on. MTR loves to help out understanding why a transfer is slow. MTR pretends to carry packets across the Internet towards the destination Please, MTR, let us know how you do it!

  1. I start by taking one hop towards, and then immediately I jump back to the start
  2. I take two hops, turn around, and return to the start
  3. I keep repeating that procedure until I've reached all the way to and returned. There could be 10-20 hops before the destination is reached
  4. For every lap I note down the time in milliseconds

The whole procedure is typically repeated 600 times, which takes 10 minutes and makes it possible to calculate an 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!

Our office is at The Park Coworking in Stockholm. Frogholm? Sprend’s server is also located in Stockholm, in the GleSYS data center. Many of our users are also located in Stockholm, which is good news for them since their files will need to travel a shorter distance. In the table below are shown the results of running MTR for 10 minutes from my MacBook, targeting the production server.

Start: 2024-03-13 16:02 (Swedish time)
No of cycles: 600 (10 minutes)
From: Sprend offices in Stockholm
To: production server in Stockholm
Hop Address Organization Packet Loss % Average time, there and back
0 My MacBook Pro Sprend
1 The Park 0 % 4 ms
2 Bahnhof 0 % 16 ms
3 Bahnhof 0 % 9 ms
4 Bahnhof 1 % 5 ms
5 Bahnhof 28 % 6 ms
6 GleSYS 1 % 5 ms
7 GleSYS 0 % 6 ms
8 GleSYS 0 % 5 ms
9 GleSYS 1 % 6 ms
10 Sprend

The IP packets have to take 10 hops to reach 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 center where the server is located.

In the column Packet Loss % we can see that very few packets are lost on the way to 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,, is configured to prioritize real packets. 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 fast 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 is however not a problem since the delay is not present in the 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 computer provided by DigitalOcean in Singapore. The target computer is still the server in Stockholm.

Start: 2024-03-13 16:26 (Swedish time)
No of cycles: 600 (10 minutes)
From: DigitalOcean data center in Singapore
To: production server in Stockholm
Hop Address Organization Location Packet Loss % Average time, there and back
0 A Linux virtual server Digital Ocean Singapore
1 Not reported Digital Ocean Singapore 100 %
2 Digital Ocean Singapore 0 % 1 ms
3 Digital Ocean Singapore 0 % 0 ms
4 Digital Ocean Singapore 0 % 0 ms
5 Digital Ocean Singapore 0 % 1 ms
6 Digital Ocean Singapore 0 % 0 ms
7 Arelion Singapore 88 % 96 ms
8 Arelion Singapore 60 % 1 ms
9 Arelion Marseille 0 % 151 ms
10 Arelion Frankfurt 0 % 157 ms
11 Arelion Frogfurt 53 % 155 ms
12 Arelion ? 0 % 233 ms
13 GleSYS Copenhagen 0 % 187 ms
14 GleSYS Malmö 3 % 165 ms
15 GleSYS Stockholm 3 % 234 ms
16 GleSYS Stockholm 4 % 256 ms
17 GleSYS Stockholm 0 % 250 ms
18 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 hop 1, 7, 8, and 11 can be safely ignored. Those routers don’t really care about the test packets that MTR sends out. 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 which has an average of 151 ms in round-trip time. In the subsequent hops this number is never lower 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 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ö (, and no 15 in Stockholm ( That distance could (?) explain the longer time needed.


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. We are going to add more examples to this articles in time.

As a Sprend user you may download MTR and run it against 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 sprending!

© Sprend 2023 Plans & Prices

Sprend Development
About us

Terms & privacy
+46 10 129 29 10