Allgemeines > Atari - Talk

Bitte testen: FreeMiNT 1-17-0 und NetUSBee auf Falcon/CT6*

<< < (7/9) > >>

m0n0:

--- Zitat ---Hoffentlich ist's nicht unhöflich, wenn ich mich da einmische
--- Ende Zitat ---

Ganz im Gegenteil, besser hätte ich es definitv nicht erklären können =)

Latz:
Hi,
@ yalsi: Vielen vielen Dank, ich hätte gleich auf Deinen Rat hören und die "superuser-shell" benutzen sollen: Jetzt funzt die Port-Weiterleitung!
Wenn ich´s recht bedenke, haben sich meine Linux-Probleme immer ziemlich leicht lösen lassen...oje, jetzt bekomme ich wohl doch Spaß daran  ;D

@m0n0: Netzwerk-sniffing funktioniert jetzt auch einwandfrei, sauber, Danke auch Dir! Ich schreibe Dir gleich ´ne PM mit den HOCHGEHEIMEN Zugangsdaten zu den NOCH GEHEIMEREN Netzwerk-Protokollen.  ;D  >:D
Habe da was von TCP checksum errors gelesen...

Gruß,
Latz

m0n0:
Hallo,

ich habe mal in den sniffer log geschaut, ist in etwa so wie ich vermutet habe - muss ich aber noch genaur verstehen.

Ich denke es ist nicht falsch wenn ich schon mal sage das Pakete verloren gehen bzw. "auf der Strecke" bleiben. Normalerweise handelt TCP das Problemlos - die fehlenden Pakete werden einfach nochmal übertragen. ( deswegen heisst es ja auch "reliable connection").

Es ist natürlich schon nicht gut das Pakete verloren gehen. Und wenn das zu oft passiert (mehr als 1%) dann müsste man eigentlich schon dagegen was unternehmen - jedenfalls wenn man interesse daran hat das die Verbindung schnell ist. Aber wir nehmen zunächst hin das es passiert. Und dann sieht man das es einen "Fehler" im FreeMiNT gibt, im Umgang mit verlorenen Paketen bzw. mit dem Wiederholen des Transfers dieser Pakete.

Das kann verschiedene Gründe haben. Aber es könnte das in der Zwischenzeit, also zwischen "Paket verloren" und "Protokoll bemerkt das Paket verloren gegangen ist" schon so viele neue Pakete verschickt wurden, das dieses nicht mehr zugeordnet werden kann (nicht mehr in Paketpuffer enthalten...?).

Ich hatte mal ein ganz ähnliches Problem mit StiNG. Ich konnte es beheben in dem Ich die TCP Window Size angepasst (erhöht) habe und die MTU runtergeschraubt habe. Soweit ich weiss, kann man die TCP Window Size mit dem FreeMiNT Protokoll Treiber nicht anpassen. Aber die MTU schon ;)

Das konnte die Probleme mit verlorenen Paketen zwar nicht gänzlich beheben ( die kleinere MTU hat aber dafür gesorgt das die Wahrscheinlichkeit das ein TCP Paket korrekt übertragen wird erhöht, ich habe weniger TCP Retransmissions gesehen), hat aber dafür gesorgt das die Verlorenen Pakete korrekt neu Übertragen werden konnten - die Verbindungsgeschwindigkeit leidet natürlich stark darunter.

Versuche doch erstmal noch folgendes:

lasse cURL mit einem Speed Limit laufen, so :
curl --limit-rate 10K http://die-grosse-datei.de -o datei.endung

und ausserdem, versuche mal mittels ifconfig die MTU runterzuschrauben. Setze doch mal auf 500 oder so... und probiere es dann nochmal.

die sourcen für ifconfig (im Freemint cvs) unterstützem Prinzipiell die MTU zu verändern... Ob das bei allen Hardware Treibern geht, das ist nicht unbedingt gesagt...

Ich werde dann nochmal den Sniff analysieren und bereinigen und dann nochmal eine Zusammenfassung der Problematik auf der MiNT liste posten, oder evt. selber eine Möglichkeit finden wie man es fixt.

Also bis denne.


Vielleicht ist auch einfach der Puffer von der Netzwekrkarte voll, und das wird nicht richtig gehandelt.... könnte auch eine simple erklärung sein, die sowas evt. hervorrufen könnte.

Latz:
Hi,
das scheint ja so als kämen wir der Sache doch noch auf die Spur...

Mit

--- Code: ---curl --limit-rate 10K <URL> -o outfile
--- Ende Code ---
lief der Download fast bis zum Ende durch, dann doch Transferabbruch.
Habe allerdings kein sniffing-log gemacht.
Mit MTU=500 läuft ein curl-DL mit ~37000 bit/s durch, diese
Einstellung ist allerdings für z.B. FalcAmp nicht zu gebrauchen.

Gruß,
Latz

m0n0:
Und wie schauts aus mit MTU = 1000 =)  ;D

Evt. doch nochmal einen Snig log machen mit einer 500er MTU... es muss immer noch relativ viele fehler geben, sonst kann eine MTU doch nicht für eine so eine gravierende Geschwindigkeitseinbuße sorgen? ... also wenn Du magst,...

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete