xDSL.at

Hallo!

Ich hab das Problem, dass die Prüfsumme von großen Downloads oft nicht stimmt (nicht immer aber oft). Kann es sein, dass FastPath daran schuld ist, obwohl TCP eine Fehlerkorrektur implementiert hat? Es sind Downloads vom Inode-FTP Server (suse.inode.at, ubuntu.inode.at, fedora.inode.at etec.)

Soll ich wieder auf Interleaving wechseln, oder ist es ausgeschlossen dass gerade FastPath solche Fehler verursacht?

lg

probier mal andere quellen (ob dies dort auch auftritt).

btw:

Hardware is sponsored by Geizhals Preisvergleich, bandwidth/rackspace is sponsored by inode

hat nichts mit einem inode-ftp zu tun, inode liefert rack und bandbreite.

lad da halt debian oder obenbsd runter, da passiert des ned *DUCK*

zwar schon etwas älter, aber trotzdem:

http://xDSL.at/viewtopic.php?t=35560&highlight=

(btw: falls das forum grade gehängt is: ich wars, die suche hat 90 sekunden gedauert )

(btw: falls das forum grade gehängt is: ich wars, die suche hat 90 sekunden gedauert )

Aha, also Du!

danke für die hilfe!

@ max_payne
also kann es durchaus sein, dass die server (mirror.inode.at) irgendwie fehlerhaft sind?...

hast du zu dem zeitpunkt fastpath aktiv gehabt?

lg

http://suse.inode.at/opensuse/distribut ... .delta.iso
soll: ed65c00012ae8caf57b617b53e37745b
1. ed65c00012ae8caf57b617b53e37745b (http)
2. ed65c00012ae8caf57b617b53e37745b (ftp)
Fastpath

habs grad probiert und die summe stimmt bei mir. die datei war ja relativ klein, nur bei 3.7 gb schauts bei mir scho anders aus

womit lädst du?

firefox, ie, filezilla, mit dem in windows integriertem ftp client

kann es sein, dass es an meinem ram liegt?.. hab zwar schonmal memtest86 drüber laufen lassen, aber nicht wirklich lange. verdächtigen tu ich im mom mal fastpath, obwohl durch TCP sowas nicht passieren dürfte

verdächtigen tu ich im mom mal fastpath, durch TCP sowas nicht passieren dürfte

mir erschliesst sich nicht ganz wie du auf diesen zusammenhang kommst.
und du weisst auch was Fastpath bewirkt?

ja klar. ich versteh nur nicht ganz was für dich nicht klar is..

wenn bei aktiviertem fastpath fehlerhafte pakete geliefert werden, müssen diese erneut angefordert werden -> packetloss, langsamer download, verbindungsabbrüche.

packetloss, langsamer download, verbindungsabbrüche.

und deswegen garantiert mir TCP immer noch eine korrekte übertragung, Fastpath oder Interleaving spielt da keine Rolle. Und deshalb ist mir nicht klar warum du Fastpath in Verdacht hast...

wicked_one hat geschrieben:

packetloss, langsamer download, verbindungsabbrüche.

und deswegen garantiert mir TCP immer noch eine korrekte übertragung, Fastpath oder Interleaving spielt da keine Rolle. Und deshalb ist mir nicht klar warum du Fastpath in Verdacht hast...

weil durch Fastpath die Korrektheit des Paketes nicht Sichergestellt wird, d.h. es könnte auch ein fehlerhaftes Paket ankommen und irgendwie durch die Fehlererkennung schlüpfen.

Beispiel:
Prüf-Verfahren, bei dem nur die Quersumme aller Bits gebildet wird.

Datenwort: 0101010101
Prüfsumme: 5

Wenn das Dantwort irgendwie durch einen Fehler verändert wird, zB auf
Datenwort: 0101010110
ist die Prüfsumme auch wieder 5.
Das sagt jetzt natürlich nichts über die Technik aus, aber Fastpath ist nicht umsonst (bei einer ordentlichen Leitung) wesentlich performanter, weil die Fehler-Überprüfung "fast" ausgeschalten wird.

und deswegen garantiert mir TCP immer noch eine korrekte übertragung, Fastpath oder Interleaving spielt da keine Rolle.

Das is allerdings richtig, TCP arbeitet sowohl mit FAstpath und Interleaving gleich, allerdings kommt es auch bei TCP vor, dass kaputte Pakete übertragen UND bestätigt werden - ich habs zumindest desöfteren erlebt.

ben hat geschrieben:Hallo!

Ich hab das Problem, dass die Prüfsumme von großen Downloads oft nicht stimmt (nicht immer aber oft). Kann es sein, dass FastPath daran schuld ist, obwohl TCP eine Fehlerkorrektur implementiert hat? Es sind Downloads vom Inode-FTP Server (suse.inode.at, ubuntu.inode.at, fedora.inode.at etec.)

Soll ich wieder auf Interleaving wechseln, oder ist es ausgeschlossen dass gerade FastPath solche Fehler verursacht?

lg

Eine Frage: Benutzt du einen Proxy-Server?