MTR - Den snabbaste grodan i dammen

Ibland när man sprendar en fil verkar det som om uppladdningen aldrig skall bli klar. Denna artikel visar hur en Sprendanvändare kan hitta flaskhalsarna i överföringen med hjälp av verktyget My Traceroute (MTR). Här finns installationsinstruktioner för Mac, Windows och Linux.

Hacka och hoppa

Om vi tar och börjar med lite bakgrund, vore det inte trevligt att få reda på hur en fil transporteras över Internet från din dator till sprend.com?

1. Först, gå till sprend.com.
2. Välj en eller flera filer från din dator.
3. Klicka på den svarta knappen Skicka.
4. Sprends webbapplikation kommer nu att läsa in den första megabyten av data från din dators hårddisk. På en Mac heter hårddisken oftast Machintosh HD och det är inte ens en hårddisk utan en mängd av sammankopplade minnes-chips.
5. Nu skickas den 1 MB stora biten till sprend.com. Operativsystemet, tex macOS eller Windows, kommer nu att dela in biten av data i små IP-paket, som normalt är 1,5 KB stora, där varje paket innehåller en liten del av filen samt vart datapaketet skall levereras.
6. Varje IP-paket överförs till Sprends serverdator via ett antal routrar. Paketet hoppar från router till router för att slutligen landa hos sprend.com.
7. Alla paket som kommer in till sprend.com pusslas ihop till en fil igen, av operativsystem Debian Linux, och därefter vidarebefordras filen till Sprends serverapplikation.
8. Sprend sparar ner filen på serverns hårddisk. Och i detta fall handlar det faktiskt om gamla klassiska magnetiska skivor som lagrar datat! Hårddiskar kan göras större än SSD-diskar och blir därför billigare per gigabyte av lagringsutrymme.

Den mycket flitiga grodan

Jag har en grodkompis som heter MTR. Han är den kvickaste hopparen i dammen. Dammen är så stor att den sträcker sig över hela jordklotet, och den är full av näckrosblad (routrar) att hoppa på. MTR älskar att hjälpa till att förstå varför en överföring är långsam. MTR låtsas att bära paket över internet mot slutdestinationen sprend.com. Snälla MTR, berätta för oss hur du gör det!

1. Jag börjar med ett hopp mot sprend.com, vänder om, och hoppar direkt tillbaka till starten
2. Sen tar jag två hopp, vänder om, och återvänder till starten
3. Jag repeterar denna procedur, med ökande antal hopp, tills jag nått hela vägen till sprend.com och återvänt. Det kan bli 10-20 hopp innan jag når slutdestinationen.
4. För varje varv noterar jag ner tidsåtgången i millisekunder

Hela proceduren repeteras sedan 600 gånger, vilket tar 10 minuter, och gör det möjigt att beräkna en genomsnittstid för varje steg. Varför bara hoppa en del av rutten och sen återvända? På så sätt kan vi ta reda på vilken router som skapar eventuella fördröjningar. Låt oss titta på två exempel.

Från Stockholm till Stockholm!

Sprends kontor finns på The Park Coworking i Stockholm. Frogholm? Sprends server finns också i Stockholm, i GleSYS datorhall i Västberga. Många av våra användare finns också i Stockholm vilket innebär att deras filer inte behöver resa så långt. I tabellen nedan visas resultatet av att köra MTR i 10 minuter från min MacBook mot Sprends produktionsserver.

Start: 2024-03-13 16:02 (Svensk tid)
Antal cykler: 600 (10 minuter)
Från: Sprends kontor i Stockholm
Till: Produktionsservern för sprend.com i Stockholm

IP-paketen behöver 10 hopp för att nå sprend.com. De första hoppen sker genom routrar från Internetleverantören Bahnhof, och den andra delen går genom stomnätet som drivs av GleSYS AB. Till slut når paketen fram till datorhallen där Sprends server fysiskt är placerad.

I kolumnen med rubrikren Paketförlust kan vi se att mycket få paket försvinner på vägen till sprend.com. Det enda oväntade värdet syns i hopp nr 5 där vi har en förlust på 28%. Om nu den routern tappar så många paket hur kommer det sig att den totala förlusten, i hopp nr 10, endast är 1%? Detta kan bero på att routern, sto-cr1.sto4-er1.as8473.net, är konfigurerad att prioritera riktiga paket. MTR skickar en typ av testpaket som en router kan välja bort att hantera. Slutsatsen är att förlusten på 28% i hopp nr 5 inte är ett problem.

I den högraste kolumnen kan vi se genomsnittstiden för ett paket att ta sig från starten, till det hopp som anges i första kolumnen, och sedan tillbaka. Genomsnittet mäts över 600 försök. Vi kan se att paketen förflyttas mycket snabbt från start till slut och tillbaka: Endast 6 millisekunder behövs för tur- och returresan. I hopp nr 2 är genomsnittstiden lite längre, 16 ms. Detta är emellertid inte något problem eftersom fördröjningen inte ackumuleras i de följande hoppen.

Från Singapore till Stockholm

In denna körning av MTR ville jag prova ett längre fysiskt avstånd med fler hopp så jag loggade in på en dator i Singapore. Måldatorn är fortfarande Sprends produktionsserver i Stockholm.

Start: 2024-03-13 16:26 (Svensk tid)
Antal cykler: 600 (10 minuter)
Från: DigitalOceans datorhall i Singapore
Till: Produktionsservern för sprend.com i Stockholm

Som förväntat behöver nu vår godmodiga groda göra fler hopp, närmare bestämt 8 fler hopp. Hoppandet startar i DigitalOceans infrastruktur, fortsätter i Arelions internationella stomnät, och slutar, som förut, i GleSYS:s nätverk.

Som i det första exempel kan paketförlusterna i hopp 1, 7, 8, och 11 utan vidare ignoreras. Dessa routrar bryr sig helt enkelt inte om de testpaket som MTR skickar ut. Det viktiga är att endast 1% av paketen har tappats bort när vi väl når sista hoppet.

Kolumnen med Genomsnittstid är intressantare nu när vår grymma groda reser till andra änden av dammen. Det mest intressanta hoppet är nummer 9 som har ett genomsnitt på 151 millisekunder. De följande hoppen tar aldrig mindre tid än så vilket indikerar att denna fördröjning kommer att finnas kvar när riktiga filer skickas. Den längre tidsåtgången är inte heller så konstig eftersom paketen i hopp nr 9 reser mellan Singapore och Marseille, vilket är ett ganska stort geografiskt avstånd.

Nästa fördröjning som ackumuleras hela vägen till sprend.com adderas i hopp nr 15, som har en tur/retur-tid på 234 ms. Namnet på routern i hopp 14 indikerar att den finnsi Malmö (be-5.cr1.mal4.se.portlane.net), och nr 15 i Stockholm (be-5.cr2.sto1.se.portlane.net). Det avståndet skulle kunna (?) förklara den större tidsåtgången.

Slutsatser

Det finns flera andra tester vi skulle kunna (eller borde) köra, från olika delar av världen som visar på olika typer av problem. Vi borde också köra testerna i den motsatta riktningen eftersom hemvägen kan skilja sig från ditvägen. Vi kommer att lägga till fler exempel till denna artikel framöver.

Som Sprendanvändare kan du ladda ner MTR och köra programmet mot sprend.com. Kontakta gärna oss så att vi kan köra MTR åt andra hållet. Tillsammans kan vi förhoppningsvis reda ut varför din överföring är långsam. Sprenda lugnt!