Solved
Download von http://www.swisslogforwindows.com/download-de.html extrem langsam
5 years ago
Hallo!
Seit geraumer Zeit muss ich leider beobachten, dass der Download von oben angeführter Seite extrem langsam ist.
Mehr als 50 - 70 KB/s sind nicht erreichbar. Ein Download einer Datei mit ca. 130 MB dauert bis zu einer Stunde.
Da mehrere User in dem Forum der Seite auch darüber klagten, haben wir versucht der Sache auf den Grund zu gehen.
Resultat war, es passiert nur bei Telekom Usern. Mehrere Tests der User mit Vodadafone, o2 und 1&1 Anschlüssen können diese geringe Geschwindigkeit nicht bestätigen. Dort war die Datei in wenigen Sekunden auf dem Rechner.
Der Betreiber der Seite, in Spanien, hat seinen Provider auch über das Problem verständigt, glaubt aber nicht, dass Dieser etwas ausrichten kann. Es sei schliesslich ein Problem der Telekom.
Meine Bitte an das Telekom hilft Team, könnt Ihr euch der Sache einmal annehmen und eventuell versuchen herauszubekommen, warum das so ist?
Viele Grüße
Ray
935
20
This could help you too
745
0
4
496
0
3
5 years ago
Lädt bei mir mit konstanten 150MB/s, dass sind > 1 MBit/s, estimate 20 min.
6
Answer
from
5 years ago
@Käseblümchen Klar. Schreibfehler. Sind 150KB/s.
Für mich sah das so aus, als ob der Server einfach nicht mehr liefert bzw. per Stream beschränkt.
Answer
from
5 years ago
Ja, wenn man einen Telekomanschluss nutzt sieht das so aus.
Ist aber nicht so.
Gerade noch mal Nachbarn um Download gebeten (Vodafone). Download mit 25 Mbits/s
Answer
from
5 years ago
hallo @Ray
anbei meine Übertragungsrate unter WLAN > swisslogSetupv5100e.exe , Kabelanschluss Telta City Netz, mit 25Mbit Anschluss.
lg
Unlogged in user
Answer
from
5 years ago
Dürfte ein Peeringthema sein.
Die Politik der Telekom ist dazu bekannt.
0
5 years ago
Der Betreiber der Seite, in Spanien, hat seinen Provider auch über das Problem verständigt, glaubt aber nicht, dass Dieser etwas ausrichten kann. Es sei schliesslich ein Problem der Telekom.
Der Betreiber der Seite, in Spanien, hat seinen Provider auch über das Problem verständigt, glaubt aber nicht, dass Dieser etwas ausrichten kann. Es sei schliesslich ein Problem der Telekom.
Das möchte ich so nicht stehen lassen.
Es wird ein Peering Problem sein.
Hier gibt es kein "Der andere ist Schuld"
Der Provider muss sich darum kümmern besser ans Netz der Telekom angebunden zu werden.
Das kostet eben Geld. Die Frage ist nun: Sind seine wirtschaftlichen Vorteile groß genug, die Mehrkosten aufzunehmen?
Am Ende müssen der Provider und die Telekom das Problem gemeinsam lösen.
1
Answer
from
5 years ago
Ja, auf solch eine hilfreiche Antwort habe ich gewartet.
Wo steht in meinem Thread etwas von Schuld?
Was immer ich beschrieben habe ist für mich ein Problem der Telekom. Denn dort bin ich Kunde und nicht bei Hinz und Kunz.
Warum haben Kunden anderer Provider, wie oben beschrieben, das Problem nicht?
Unlogged in user
Answer
from
5 years ago
das hat in der Regel damit zu tun, wie viele Kapazitäten zwischen dem Bereich des Providers liegen, in dem der Server betrieben wird, und unserem. Und manchmal auch noch, je nach Route, zwischen dem des Servers, dem dazwischen und unserem.
Ohne mindestens einen tracert-Bericht zwischen deinem Anschluss und dem Server zu kennen, kann ich dazu so überhaupt nichts sagen.
Ein tracert gibt Auskunft darüber, wo im Verlauf der Route es zu langen Warte-/Ladezeiten kommt, damit komme ich der Sache näher.
Oft entstehen diese langsamen Raten und langen Ladezeiten an den Übergabepunkten zwischen den zwei Netzbereichen unterschiedlicher Hoster.
Ermitteln kann so ein Test allerdings auch höchstens, wo genau es hakt, indem er die Stelle identifiziert. Danach müssen die jeweiligen Hoster tätig werden. In unserem Fall kann ich dir in die Hand versprechen: Solche Engpässe werden automatisch beobachtet, notiert und nach Möglichkeit ausgebaut, um diese Verzögerungen zu vermeiden. Was wir nicht können: Auf der Seite des jeweils anderen Hosters/Providers für mehr Kapazitäten sorgen. Und nur, wenn auf beiden Seiten das Tor groß genug ist, geht auch genug Datentransfer durch.
Deshalb kann es natürlich sein, dass ein Vodafone-Kunde von seinem Vodafone-Netzbereich aus ein größeres oder aber weniger stark frequentiertes Tor in den Bereich deines Servers hat - oder dass der Server bei Vodafone steht. Das kann ich ohne Daten nicht beantworten und könnte es auch mit Daten nur sehr in Maßen supporten, doch ich hoffe, dir hilft die Erklärung zumindest bei der Lösungsfindung.
Viele Grüße
Anna Si.
1
Answer
from
5 years ago
Hallo @Anna J.
Recht herzlichen Dank für den Versuch mir das Ganze zu Erklären.
Da ich nun überhaupt keine Ahnung von Routing etc. habe, nehme ich das natürlich so hin. Trotz deiner verständlichen Erklärung bleibt das Ganze für mich allerdings wirklich ein schwarzes Loch
Tracert habe ich 2 mal gemacht und das ist dabei heraus gekommen:
Routenverfolgung zu swisslogforwindows.com [185.162.171.236]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms 192.168.2.1
2 5 ms 5 ms 7 ms p3e9bf4c6.dip0.t-ipconnect.de [62.155.244.XXX]
3 10 ms 10 ms 10 ms pd900cb1e.dip0.t-ipconnect.de [217.0.203.30]
4 18 ms 13 ms 12 ms 80.157.201.198
5 10 ms 10 ms 10 ms be3187.ccr42.fra03.atlas.cogentco.com [130.117.1.118]
6 20 ms 20 ms 21 ms be2800.ccr42.par01.atlas.cogentco.com [154.54.58.238]
7 33 ms 33 ms 33 ms be2318.ccr32.bio02.atlas.cogentco.com [154.54.61.117]
8 37 ms 37 ms 37 ms be2325.ccr32.mad05.atlas.cogentco.com [154.54.61.134]
9 38 ms 38 ms 38 ms be3379.agr22.mad05.atlas.cogentco.com [154.54.39.146]
10 36 ms 36 ms 36 ms te0-0-2-2.nr11.b046976-0.mad05.atlas.cogentco.com [154.25.2.50]
11 39 ms 39 ms 38 ms 185.162.171.1
12 * * * Zeitüberschreitung der Anforderung.
13 39 ms 39 ms 39 ms s9.gestiondeservidor.com [185.162.171.236]
Ablaufverfolgung beendet.
C:\WINDOWS\system32>tracert www.swisslogforwindows.com
Routenverfolgung zu swisslogforwindows.com [185.162.171.236]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms 192.168.2.1
2 4 ms 4 ms 5 ms p3e9bf4c6.dip0.t-ipconnect.de [62.155.244.XXX]
3 11 ms 10 ms 10 ms pd900cb1e.dip0.t-ipconnect.de [217.0.203.30]
4 13 ms 12 ms 12 ms 80.157.201.198
5 11 ms 10 ms 10 ms be3187.ccr42.fra03.atlas.cogentco.com [130.117.1.118]
6 21 ms 21 ms 20 ms be2800.ccr42.par01.atlas.cogentco.com [154.54.58.238]
7 33 ms 33 ms 33 ms be2318.ccr32.bio02.atlas.cogentco.com [154.54.61.117]
8 37 ms 38 ms 38 ms be2325.ccr32.mad05.atlas.cogentco.com [154.54.61.134]
9 38 ms 39 ms 38 ms be3379.agr22.mad05.atlas.cogentco.com [154.54.39.146]
10 * 40 ms 36 ms te0-0-2-2.nr11.b046976-0.mad05.atlas.cogentco.com [154.25.2.50]
11 55 ms * * 185.162.171.1
12 39 ms * 39 ms s9.gestiondeservidor.com [185.162.171.236]
Ablaufverfolgung beendet.
Mir sagt das natürlich nichts, aber Dir vielleicht.
Das Einzige was mich halt stört ist die Tatsache, dass der Download von dieser Seite einfach nicht vernünftig klappt.
Mal sehen, ob Dir dazu noch etwas einfällt.
LG Ray
Unlogged in user
Answer
from
5 years ago
ich habe da jetzt ein bisschen für gebraucht, entschuldige bitte.
Die erste Route habe ich mal auseinandergepflückt und überprüft, welche IPs zu wessen Netz gehört, angefangen bei der letzten in unserem Netz:
4. 80.157.201.198 – DTAG
5. 130.117.1.118 – PSINet
6. 154.54.58.238 – COGENT
7. 154.54.61.117 – COGENT
8. 154.54.61.134 – COGENT
9. 154.54.39.146 – COGENT
10. 154.25.2.50 – COGENT
11. 185.162.171.1 – REDSERVICIO-MAD-NETWORK
13. 185.162.171.236 – REDSERVICIO-MAD-NETWORK
Den 12. Hop konnte ich wegen fehlender Daten durch die Zeitüberschreitung nicht ermitteln, da davor und danach aber der gleiche Hoster steht, dürfte das auf 12 auch zutreffen.
Was daran zu sehen ist, ist dass die Anfrage schon nach dem 4. Hop unser Netz verlässt und IPs im Netz der Firmen PSINet, Cogent Communications und schließlich des venezolanischen Betreibers REDSERVICIO verwendet.
Die Zeitüberschreitung bei der Anforderung könnte ein Hinweis auf die Ursache für Verzögerung in der Datenübertragung sein. Da ein einzelner Ping keine große Datenmenge ist, findet sie sich hier nicht genauso wieder. Ich vermute allerdings, dass es an einem der Übergabepunkte zwischen anderen Netzbetreibern liegt, also müssten diese ihre Kapazitäten für die Datenübergabe untereinander erhöhen.
Interessant wäre nun, einen tracert zum Vergleich zu haben von jemandem, der die sehr langsame Download-Rate nicht hat.
Jedoch liefert das, wie gesagt, lediglich eine Erklärung, leider nicht unbedingt eine Lösung. 😕
Viele Grüße
Anna Si.
6
Answer
from
5 years ago
Und wenn wir jetzt noch erfahren könnten, an welchen Knöpfchen @Anna J. drehen konnte, hätte man ja Tipps für die Zukunft parat.
Answer
from
5 years ago
@wolliballa
Und wenn wir jetzt noch erfahren könnten, an welchen Knöpfchen @Anna Si. drehen konnte, hätte man ja Tipps für die Zukunft parat.
Das wir Sie uns wohl nicht verraten 😏
Aber wer immer ein gleichartiges Problem hat, wende sich vertrauensvoll an @Anna J.
Da werden Sie geholfen.
Answer
from
5 years ago
@wolliballa tatsächlich habe ich nichts weiter unternommen, außer die Zusammenhänge hier zu erklären.
Ich gehe davon aus, dass die fehlenden Kapazitäten bei COGENT und/oder PSINet inzwischen erweitert wurden, sodass der bisherige Engpass nicht mehr besteht.
Empfehlen würde ich in solchen Fällen, wie schon zuvor geschrieben, über einen Tracert, wie hier geschehen, zu ermitteln, wo dieser Engpass vermutlich sitzt, und die entsprechenden Hoster zu kontaktieren.
Allen einen schönen Abend und passt auf euch auf!
Viele Grüße
Anna Si.
Unlogged in user
Answer
from
Accepted Solution
accepted by
5 years ago
Moin @Anna J. , hallo Mitleser,
es ist vollbracht. Seit gestern funktioniert der Download in einer wahnsinns Geschwindigkeit.
Deshalb mein spezieller Dank an @Anna J. , die mit ihrer Fachkenntnis und ihrer Geduld es geschafft hat, ein Problem zur Zufriedenheit des Kunden zu lösen.
Mit solch engagierten Mitarbeiterinnen und Mitarbeitern kann die TK überall punkten.
Grüße und Dank
Ray
0
Unlogged in user
Ask
from