Trage download Jottacloud (max 18,5 Mbps)

[nescafe]

Momenteel heb ik Jottacloud Unlimited in gebruik om middels Duplicati automatisch backups te maken van een drietal werkstations. Dit werkt naar wens - bij het uploaden heb ik een prettige bandbreedte, zo ongeveer 60 Mbps.

Nu ik iets wil herstellen uit de backup blijkt het restoren echter fors meer tijd te kosten dan door mij voorzien.

Voorbeeld: een restore van 95 GB zou naar mijn idee ong. 8 uur mogen duren. Hierbij ga ik uit van 60 Mbps traffic en 100% overhead door de volume-size en verification. Deze restore kostte uiteindelijk 4 dagen.

Hierbij wordt de bandbreedte vrij strak gelimiteerd op 18,5 Mbps:



Via http://speedtest.jottacloud.com/ is de downloadsnelheid hoger (90 Mbps), maar alleen door de meerdere streams die zijn geopend. Per connectie is de bandbreedte 18,5 Mbps:





Ter vergelijking speedtest.net vanaf hetzelfde werkstation:


Het feit dat er per connectie wordt geknepen doet vermoeden dat er sprake is van connection tracking, dus aan de serverzijde, maar uit mailwisseling met de supportdesk blijkt dit niet geval te zijn. Een file van 646 MB komt volgens hen "instantly" binnen dus i.i.g. sneller dan 18,5 Mbps.

Ze geven aan dat de hoge ping (30ms) van invloed kan zijn op de snelheid maar bevestigen ook dat een (single stream) speedtest naar mijn host een resultaat geeft van 103 Mbps down en 208 Mbps up.

Mijn vraag:

• Wil/kan er iemand de snelheid controleren van de download van deze Ubuntu iso vanaf Jottacloud?
• Heeft er iemand andere ervaringen met Jottacloud en met het downloaden van bestanden?
• Is er een andere verklaring te vinden voor dit verschijnsel?

Relevante software en hardware die ik gebruik
Duplicati 2.0.3.3, HP Microserver N40L, HP ML350 Gen9, Dell XPS 15 9560

Wat ik al gevonden of geprobeerd heb

• Andere locaties, werkstations, servers en providers (Tweak, Caiway, Weserve)
• Verschillende browsers (Chrome/IE/Edge)
• Ander (tijdelijk) Jottacloud-account
• Ander tijdstip ('s middags / 's avonds / 's nachts), heeft invloed op de totale bandbreedte maar niet op de bandbreedte per connectie

[ehtweak]

ff snel getest voor je, vanuit een browser (FF):


en als ik tegelijkertijd via de Resource Monitor de network I/O bekijk, dan zit die tegen de 18Mbps aan.

(alles vanaf een 100/100 FttH verbinding)

En een speedtest van mijn verbinding, geeft op dit moment:


Volgens Jottacloud zijn ze gevestigd in Oslo.
Een speedtest richting Oslo:


M.a.w. die pingtijd van ca. 30ms komt gewoonweg overeen met de afstand NL <--> Oslo.

[ Voor 44% gewijzigd door ehtweak op 07-12-2018 23:24 ]

[Brahiewahiewa]

Wat voor snelheid haal je als je van een locale server (in je eigen netwerk dus) restored?

[ Voor 10% gewijzigd door Brahiewahiewa op 08-12-2018 00:02 ]

[nescafe]

Dat ga ik morgen even testen. Op zich voer ik mijn tests rechtstreeks in de browser uit, dus is Duplicati nu niet relevant, maar wel interessant om te zien wat haalbaar zou moeten zijn in een restore-scenario.

Ik heb nog twee tests gedaan: 1 op een AWS EC2-instance en 1 op een Azure-instance. Beide geven ~15Mbps voor de download van Jottacloud en halen ruim 100Mbps of het dubbele bij een reguliere speedtest.

Deze bevindingen (samen met die van ehtweak) heb ik zojuist als supportissue ingeschoten, aangezien het verifieerbaar traag is.. ze mogen nu wel met iets anders komen dan it works on my machine

[krakendmodem]

Hier gaat het downloaden van de iso maar met 12,5Mbit (1,4MB/s) in Firefox. Gebruik ik een download manager, dan schommelt deze zo rond de 40Mbit down. Is opzich logisch, deze start een stuk of 10 sessies op waardoor die sneller downloadt.




KPN 50/10 verbinding via VDSL.



Ook bij het verbinden naar een VPN server in Oslo (Airvpn) krijg ik niet meer dan 12Mbit erover heen. Andere downloads komen met de volle 50Mbit binnen.

[nescafe]

Dankzij het antwoord van @krakendmodem ben ik verder ingedoken op het parallel (opgesplitst) kunnen downloaden van een file d.m.v. het opgeven van een http range header in de REST API van Jottacloud:



Hiervoor heb ik de backend in Jottacloud voorzien van twee parameters, threads en chunk size:



Het resultaat is er



Restore komt nu gemiddeld rond de 60 Mbps uit, dus 4 threads lijkt afdoende (en wat 12 overdreven ).

Het aantal gelijktijdige connecties tijdens restore:



Source: https://github.com/nescaf...1f31066fbe5850c44a5a9bb0f

Hiermee is het probleem w.m.b. dus opgelost!

@Brahiewahiewa heb nog even een restore van 42,5 GB gedaan met nextcloud als backend (via webdav), restore-tijd incl. verificatie 25 minuten.

nescafe schreef op zaterdag 8 december 2018 @ 22:17:
Dankzij het antwoord van @krakendmodem ben ik verder ingedoken op het parallel (opgesplitst) kunnen downloaden van een file d.m.v. het opgeven van een http range header in de REST API van Jottacloud:

[Afbeelding]

Hiervoor heb ik de backend in Jottacloud voorzien van twee parameters, threads en chunk size:

[Afbeelding]

Het resultaat is er

[Afbeelding]

Restore komt nu gemiddeld rond de 60 Mbps uit, dus 4 threads lijkt afdoende (en wat 12 overdreven ).

Het aantal gelijktijdige connecties tijdens restore:

[Afbeelding]

Source: https://github.com/nescaf...1f31066fbe5850c44a5a9bb0f

Hiermee is het probleem w.m.b. dus opgelost!

@Brahiewahiewa heb nog even een restore van 42,5 GB gedaan met nextcloud als backend (via webdav), restore-tijd incl. verificatie 25 minuten.

toon volledige bericht

Edit/toevoeging:

Er is per 09-01-2019 een wijziging in de algemene voorwaarden doorgevoerd waarin de bandbreedtebeperking is opgenomen:

quote: https://www.jottacloud.com/en/terms.html

Jottacloud’s personal subscription with unlimited storage was created to provide customer predictability. Unlimited refers to available storage. Limitations on bandwidth and the number of api calls may occur.

[ Voor 42% gewijzigd door nescafe op 15-01-2019 11:10 ]