atari-home.de - Foren
Allgemeines => Atari - Talk => Thema gestartet von: Latz am Mo 18.07.2011, 12:23:59
-
Hi,
auf den Falcons/CT6* habe ich ein Problem mit der NetUSBee und MiNT 1-17-0/1-18-CUR:
Getestet auf:
- Falcon/CT60@80MHz/CTPCI, clockpatch auf U63
- Falcon/CT63@66MHz, kein clockpatch, SDMA patch 50 Ohm/27 pF
mit den Treibern
- enec6.xif (CT60 Archiv oderr www.newtosworld.de)
- ne2kenec.xif (http://assemsoft.atari.org/ne2k/)
- inet4.xdd (freemint build oder http://assemsoft.atari.org/ne2k/)
Größere Downloads (z.B. der FreeMint daily build)
bleiben irgendwann (jedesmal an einem anderen Punkt) hängen, egal welchen Treiber ich
verwende (aus dem CT60-Archiv, von NewTosWorld oder von der AssemSoft-Seite). Das passiert
mit HighWire genauso wie mit "wget" auf der Konsole, auch bei ftp im Netz und zum/vom PC.
Das betrifft nur größere Dateien, wenn z.B. eine Webseite aus vielen kleinen Dateien besteht
(google Bildersuche) läuft alles schnell und korrekt.
Die Verbindung ist nicht wirklich unterbrochen aber der Download stoppt; auch FalcAmp hat
sofort "buffer underrun"-Probleme.
- NetUSBee ist OK (StinG/TOS060, EasyMiNT).
- Ping (egal wohin) funktioniert einwandfrei, keinerlei Paketverluste auch bei 100 Paketen.
- ifconfig zeigt keine Fehler, netstat und traceroute ebenfalls.
- config.if, defaultroute, resolv.conf, hostname, /stik_cfg/default.cfg, /highwire/modules/...
sind auch alle korrekt
- Router und Netzwerkkabel sind auch OK.
Denn: Mit der EasyMiNT-Installation (FreeMiNT 1-16-3) läuft alles einwandfrei-Downloads egal
welcher Größe laufen mit ~119 kB/s, FalcAmp spielt stundenlang InternetRadio ohne Probleme.
Klar hängt das irgendwie an MiNT; ich brauche aber hauptsächlich ein paar Testberichte ob Ihr
mit dieser Hard- und Software auch dieses Problem habt (oder wie es bei Euch funzt).
Bitte soviele Infos wie möglich über Hardware, Software und -Einstellungen (CT-, MiNT und
HDDriver-Caches, MiNT-Version, DL-Geschwindigkeit, ...), sonst kann ich das Problem
niemals aussortieren...
Danke vorab,
Latz
-
unabhängig von deinem problem, wozu ich nichts sagen kann weil ich kein mint habe (der falcon und ct60 etc fehlt mir auch..)..
sollte der clockpatch nicht generell bei betrieb einer ct60 raus?
-
Ich konnte (beim 2. Falcon) keinerlei Unterschied zwischen Clockpatch
und kein Clockpatch feststellen; Nr.1 läuft seit jeher mit CT60 UND
Clockpatch. Allerdings ist bei beiden Falcons das MB nicht beschleunigt.
Latz
-
Hallo, ist es dir möglich mit einem 1.16.3er Kernel die aktuellen Netzwerk Kernel Module zu laden? ( also inet4.xdd, enec.xif etc...) - ich weiss nicht ob es da einen Versioncheck gibt...
aber wenn Du das mit neuen Modulen und altem kernel testest und es geht immer noch - dann weiss man zumindest schon mal das das Problem im Kernel und nicht innerhalb der einzelnen Module zu suchen ist...
Sollte der Test mit altem kernel und aktuellen Modulen zum selben Fehler führen, dann ist das Problem innerhalb der Module zu suchen... Da könnte man dann nochmal den umgekehrten Test fahren: neuer Kernel - alte Module, - um die Theorie zu untermauern.
Ich weiss das Alan einige änderung im select() call gemacht hat. Evt. kommst Du an eine 1.17 beta ran ( z.b. die aus uMiNT von mikro ) und schaust ob das Problem auch mit dem Kernel auftritt der dort enthalten ist. Ich glaube sogar das ist die beste Idee und das solltest Du als erstes probieren - wenn das Problem mit dem uMiNT kernel (und den aktuellen Modulen aus 1.18) nicht auftritt, dann ist es schonmal Zeitlich sehr gut eingegrenzt und ich denke es sollte durchaus möglich sein das Problem zu finden.
uMiNT distr: http://mikro.naprvyraz.sk/files/uMiNT.zip
Aber bitte alles vorher sichern, nicht das es da nachher unordnung gibt ;)
-
Hi mOnO,
das haben wir auf der mintlist (mehr oder weniger) geklärt, ist
ca. 1 Monat her. Da hat Alan die Versions-Abfage aus dem inet4.xdd
vom 1.16.3er entfernt und ich habe inet4.xdd auf 1-18-cur probiert.
Dieselben Probleme... Das Thema ist dann irgendwwie im Sande
verlaufen, habe gedacht ich frage erst nochmal wie's anderen Leuten
so geht bevor ich das Thema in der mintlist wieder "aufwärme".
Danke für den Tipp mit dem umint.zip, teste ich die Tage!
Latz
-
Ja bitte, ich setze 0,10€ das es mit dem uMiNT kernel geht! ;)
-
Bitte überweise 0.10 Euro auf mein Konto Nr.... ;D
Leider funzt es auch mit dem uMint kernel nicht; das ist
ja auch ein 1.17. War aber auf jeden Fall ein Versuch wert.
Latz
-
Das ist nicht nur ein versuch - es wäre doch gut wenn man das Problem Zeitlich eingrenzen könnte.
Hast du es auch mit inet4.xdd / enec treiber aus der umint distri probiert?
Edit:
du könntest mit "ifconfig" auch nochmal schauen ob die MTU auf den selben wert gesetzt ist....
-
NOCH WAS ;D
Ich habe noch eine gute idee wie man dem Problem etwas näher kommen kann, lade dir cURL für FreeMiNT herunter:
http://freeshell.de/~monokrom/monochrom.net/atari/ports/curl-7.21.4-1.m68kmint.rpm
installieren ( falls Du kein rpm hast, auf dem PC mittels WinRAR, midnight commander oder einem anderem guten Archiver tool das Archiv entpacken und den Ordner bin auf den Atari kopieren...).
Und dann so aufrufen:
curl http://wasweissich.de/einesehrgroßedatei.zip -o testdatei.zip --trace error.log
Evt. Fehlermeldungen inkl. Fehlernummer hier posten und den Inhalt des Trace Files auch.
-
Hi,
klar habe ich es auch mit inet4.xdd aus dem umint-archiv probiert,
ebenfalls dasselbe Problem.
MTU-Einstellungen auch mehrfach geprüft.
Das mit cURL teste ich und sage dann Bescheid, danke!
Latz
-
Hallo,
hier die Testergebnisse (freemint 1-17-0 und 1-18-cur):
curl http://www.fairlite.demon.co.uk/FreeMiNT/builds/freemint/trunk-26072011.tar.bz2 -o /tmp/testrunk.zip --trace error.logund
curl http://www.fairlite.demon.co.uk/FreeMiNT/builds/freemint/helmut-26072011.tar.bz2 -o /tmp/testhelm.zip --trace error2.logDie Dateien werden vollständig heruntergeladen; genau wie mit wget --read-timeout=5Siehe mintlist Thema http://sparemint.org/mailinglist/Mailing-Lists/MiNT-List.201106/003bd41e.01a083b2e062@mail.gmx.net.text
Aber jedes Paketsegment wird mindestens zweimal geladen; manche sogar fünfmal, bevor der "Zähler" (1. Spalte bei der Konsolen-Ausgabe von
curl) eins weiterspringt.
Jetzt habe ich hier 2 ca. 20MB große error.log Dateien (gezipped ~10MB) die mir persönlich nicht viel sagen und die
ich hier auch nicht posten kann.
Also wohin damit? ???
Latz
-
Wieso, wenn die Dateien vollständig geladen werden, dann ist doch alles OK >:D
Nein, uploade es doch bei einem File-Upload service (z.b. http://www.file-upload.net/ ?) und schick mir dann die URL per PM.
Segmente die mehrfach übertragen werden, deuten u.a. auf eine inkompatibilität der Ziel / Ursprungs TCP Stacks hin... Da wäre es sehr nützlich einen Sniffer-Log zu haben - meinst Du, Du kannst sowas erstellen? ( mit wireshark z.b.).
Ansonsten versuche auch curl nochmal ohne trace aufzurufen - aber mit -v und leite du ausgabe in eine Logdatei um. Die entstehenden Dateien sollten kleiner sein.... Evt. die Logs dann hier posten oder auch uploaden.
-
Hi,
muß erst die Dateien vom Falcon auf den PC schieben, dann vom PC aus
hochladen, mein Provider "schenkt" mir online-Speicherplatz.
Ich sage dann Bescheid.
Sniffer-Log mit wireshark: Wenn Du mir ein paar Tipps gibst...bin nicht
ganz so "firm" in der Benutzung.
Ich habe (dachte ich) schon recht viel über Konsolen-Befehle gelernt aber "umleiten der
Ausgabe in eine Datei" war irgendwie nicht dabei :-\\
Also curl -v <http://langedatei.zip>und wie weiter?
Dank und Gruß,
Latz
-
OK, das error.log von curl findet sich hier:
http://latzmaster.kabelhomepage.de/fotoalbum/fotoalbum_detail.asp?selectedMediaID=1&selectedAlID=1&mediatype=textfile (http://latzmaster.kabelhomepage.de/fotoalbum/fotoalbum_detail.asp?selectedMediaID=1&selectedAlID=1&mediatype=textfile)
Bitte .pdf in .zip umbenennen.
Latz
-
Hallo,
im error.log ist kein einziger retransmit zu sehen, wurde so eine meldung denn auf der konsole ausgegeben?
Falls ja, dann müssen wir die Zuletzt beschriebene Methode verwenden um die Fehlermeldungen der Konsole in die Datei zu bekommen.
Umleitung der Ausgabe von curl in eine Datei ( geht auch bei jedem anderen Konsolen Prg. so):
curl -v bla.de/bla.zip > ausgabe.log
Ansonsten - nehme ich an das diese Übertragung absolut sauber ablief und es kein Problem gab,... in so einer Situation kann man natürlich auch keine Fehlermeldung analysieren....
-
Hi,
Ausgabe in Datei: Aaargh, das war wohl zu einfach für meinen hochentwickelten Intellekt ;D
Ok, hier curl_output.pdf (http://latzmaster.kabelhomepage.de/fotoalbum/fotoalbum_detail.asp?selectedMediaID=2&selectedAlID=1&mediatype=textfile) (bitte wieder in .zip umbenennen)
finden sich drei Ausgaben mit
curl -v <webadresse> > curl_output*1. Daily freemint builds trunk
2. Daily freemint builds helmut
3. tos060.lzh von Didier´s Seite
Alle drei habe ich mit CTRL-C abgebrochen, nachdem nach kurzer Zeit gar nix weiter ging. Komischerweise sind diese Ausgabedateien kein txt...
Gruß,
Latz
-
Sorry, war mein Fehler, du musst nicht die normale Ausgabe umleiten, sondern die Fehler Ausgabe, das geht so:
curl google.de -v --retry 3 --retry-max-time 15 --connect-timeout 15 2> log.txt
Bitte auch die timeouts beachten...
Also noch einmal :)
-
Hihi,
hast Du wirklich mal probiert was Du da geschrieben hast?
Wenn ich das hier (mit der FreeMiNT- daily build Adresse)
probiere, verwandelt sich TosWin2 in eine 70er-Jahre Disco:
Die Hintergrundfarbe wechselt öfters und dauernd kommen Alert-Pings
aus dem Speaker...spaßig, aber nicht wirklich hilfreich ;D
Aber ich habe nochmal zwei Testläufe mit
curl -v --retry 3 --retry-max-time 15 --connect-timeout 15 -o /tmp/curl.tar.bz2 http://www.fairlite.demon.co.uk/FreeMiNT/builds/freemint/*-03082011.tar.bz2gemacht. Der Fehler ließ nicht lange auf sich warten, somit konnte
ich per drag'n'drop die Ausgabe sichern: Angehängt, bitte wie immer in .zip umbenennen.
Edit: Habe es auch mit den options VOR der Adresse probiert, ebenfalls ohne
SPACE zwischen "2>" und "curl_out.txt", immer dasselbe: DISCO 8)
Gruß,
Latz
-
hm, ... tja, das sagt uns leider nicht viel :( Es fällt mir aber auf... bei Deinem ersten versuch hat es doch problemlos geklappt! ( der bei dem Du so viele Daten geloggt hast - 20mb...) - war das zufall, oder lässt sich das reproduzieren mit den entsprechenden curl parametern?
Ich könnte mir vorstellen das das schreiben der trace-datei das system verlangsamt und es deshalb nicht zum fehler kommt...
Wir wären trotzdem gut beraten wenn Du den Traffic sniffen könntest. Kannst Du kurz mal dein Netzwerk Setup erklären? (windows/linux, router, struktur etc...).
Dann fällt mir evt. etwas ein wie man das sniffing in deinem Netzwerk machen kann, oder du holst dir einen HUB, und schliesst den vor deinen x86 PC und den Falcon.... ein Hub leitet alle Pakete an alle Rechner weiter (im gegensatz zum switch) und kann deshalb sehr gut zum sniffen verwendet werden....
-
Hi,
in der Tat, es ist reproduzierbar:
curl <URL> -o outfile --trace error.logfunktioniert immer. Dann hast Du anscheinend Recht, das schreiben
der error.log bremst. Könnte das nicht auf ein Daten/Cache-handling-Problem
in MiNT hinweisen (habe ich auch schon in der MiNTlist "orakelt")??
Meine Netzwerk-Topographie:
- d-link Router, an dem hängen alle Rechner (LAN)
-> PC, Ubuntu-Linux
-> Falcon No1
-> Falcon No2
Gruß,
Latz
-
Hi,
erstmal vielen Dank an mOnO für die tatkräftige Unterstützung!
Aber es kann doch nicht sein daß ich der Einzige mit dieser Systemkonfiguration bin!
Vielleicht habe ich Euch auch mit der Menge der gewünschten Angaben abgeschreckt :P
Also nochmal gaaanz einfach: ;)
Wenn jemand Falcon/CT6* + MiNT + ROMport-Netzwerkarte/Adapter benutzt,
bitte kurz schreiben
- was für'n MiNT
- welche Netzwerkkarte/ROMport-Adapter
- wie's läuft (DL-Geschwindigkeit mit Highwire oder wget).
Dank+Gruß,
Latz
-
Hallo,
bevor Du den Debug kernel installierst, könntest Du bitte nochmal versuchen die Trace datei nicht auf eine Festplatte, sondern in auf die FreeMiNT Ramdisk zu schreiben? Das sollte 1. weniger Geschwindigkeitseinbußen, 2. keine oder andere Interrupts / DMA Transfers auslösen.
(also /ram bzw. U:\ram )
...Ist immer Gut zu schauen unter welchen Bedingungen etwas (nicht) passiert....
Grüße...
-
Sackl Zement, der Mann hat gute Ideen, wieso komme ich da nicht selbst
drauf? :o
Aber es bleibt dasselbe Verhalten. Mit
curl http://www.fairlite.demon.co.uk/FreeMiNT/builds/freemint /trunk-05082011.tar.bz2 -o /tmp/testtrunk.tar.bz2 --trace /ram/error_ram.logläuft der Download durch (average speed 21500). Ich denke, das "posten" der 20MB error.log kann
ich mir daher sparen.
Ohne "--trace" ist die Geschwindigkeit (bis zum Abbruch) deutlich höher (~55000)...
und dann hört's einfach auf.
Also dann doch mit dem debug-kernel.
Gruß,
Latz
-
Also dann doch mit dem debug-kernel.
"dann doch" ist falsch - das war ja eh nicht gecancelt ;)
Ich würde an deiner Stelle aber auch meine Idee mit dem sniffen in angriff nehmen. Ich werde Dir demnächst ein paar shell kommandos posten mit denen Du deinen Linux Rechner als Router konfigurierst... dann musst Du unter Freemint noch das gateway einstellen.... und dann sollte jeglicher traffic über deine Linux Box gehen. Dann werden 2 Logs gesnifft - einmal mit Fehler, einmal ohne.... Ich tippe zu 70% das Mint irgenwas unternehmen will um den Netzwerk-traffic zu bremsen ( auf tcp ebene ) und das irgendwie in die hose geht ( ebenfalls auf tcp ebene...) .
-
Hier sind die Kommandos mit denen Ich meinen Rechner als NAT Router konfigurieren kann:
modprobe iptable_nat
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
Bitte beachten das evt. das Netzwerkinterface (hier eth0) an Deine Gegebenheiten angepasst werden muss, die Namen deiner Netzwerkkarte kannst Du mit dem Kommando "sudo ifconfig" erfahren - das 127.0.0.1 interface bitte einfach ignorieren!
Dann muss man unter freemint noch mittels des route kommandos die Default route umschreiben.... so das nicht mehr der von DHCP zugewiesene Router verwendet wird, sondern halt die Linux box... da muss ich aber erst nochmal schauen, oder Du machst Dich anderweitig schon mal schlau....
Edit:
Ich denke ich kann jetzt sagen wie Du unter MiNT das gateway einstellst... ( ist aber nur teilweise getestet, weil ich im Moment kein Hardware-Setup habe mit dem ich das so wie bei Dir nachstellen kann - sollte aber gehen ;) )
route del default
route add default ne0 gw die_ip_deines_linux_rechners
beim zweiten kommando muss darauf geachtet werden das ne0 evt. durch den namen Deines interfaces ersetzt werden muss - falls abweichend. Die Namen der Netzwerkschnittstellen kannst Du Dir mit dem Kommando "ifconfig" ausgeben lassen.
nun probierst du unter Mint - ob Du wie bisher google.de pingen kannst - falls ja, dann scheint alles geklappt zu haben.
Danach installiert du das tool wireshark auf Deiner Linux box.
...und startest es so:
sudo wireshark -k -i eth0
Evt. Netzwerkinterface bei dem Kommando anpassen, s.o....
Sobald Du nun einen ping unter FreeMiNT absetzt sollte das in Wireshark zu sehen sein.... wenn alles geht - gehts los mit sniffen.
Du machst jeweils 2 Testdurchläufe - d.h. Du startest wireshark, machst den Testlauf, speicherst den Log und beendest Wireshark wieder....
1. Durchlauf - Test mit Curl und --trace eine_Datei
2. Durchlauf - Test mit Curl und ohne Trace
Speichern des Paket-Logs:
Klick auf Symbol mit Rot umkreisten Weissem X - auf einer Netzwerkkarte, tooltip: Stop the running live capture.
Danach Im Menü "File" -> "Save As" auswählen. Und dann sinnvoll benennen und Speichern...
Die beiden Logs bitte packen und wieder hochladen. Aus Sicherheitsgründen bitte die URL per PM an mich.
Noch eine Bitte: Dafür sorgen das so wenig Netzwerkprogramme wie möglich nebenher laufen.... dann sind nicht so viele nicht benötigte Pakete in der Datei enthalten.
Grüzi
-
Uff, danke für die ausführliche Anleitung (solltest Du ins Wiki schreiben,
wenn's bei mir auch funzt)!
Ich mache mich ran und sage dann Bescheid!
Gruß,
Latz
-
Hi,
ich mach´s kurz (Ubuntu 10.04):
modprobe iptable_natgibt die Meldungen:
WARNING: All config files need .conf: /etc/modprobe.d/ndiswrapper, it will be ignored in a future release.
WARNING: All config files need .conf: /etc/modprobe.d/nvidia-kernel-nkc, it will be ignored in a future release.
Bei
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADEmusste ich "sudo" davorsetzen damit es geht.
sudo echo 1 > /proc/sys/net/ipv4/ip_forwardgibt allerdings immer die Fehlermeldung:
bash: /proc/sys/net/ipv4/ip_forward: Keine BerechtigungPing vom PC ins Netz geht.
Mit dem MiNT net-setup kenn´ ich mich aus :D
Defaultroute ist <PC-IP>, ping zum PC geht, ping zum router oder ins Netz geht nicht.
Wie kriege ich das hin?
Gruß,
Latz
-
Hallo Allerseits
Hoffentlich ist's nicht unhöflich, wenn ich mich da einmische- ich liebe nur Linux-Probleme:
modprobe iptable_natgibt die Meldungen:
WARNING: All config files need .conf: /etc/modprobe.d/ndiswrapper, it will be ignored in a future release.
WARNING: All config files need .conf: /etc/modprobe.d/nvidia-kernel-nkc, it will be ignored in a future release.
Das kannst Du ersteinmal ignorieren. Wenn Du ein
sudo lsmod | less
machst, sollte iptable_nat in der Liste auftauchen.
Bei
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADEmusste ich "sudo" davorsetzen damit es geht.
sudo echo 1 > /proc/sys/net/ipv4/ip_forwardgibt allerdings immer die Fehlermeldung:
bash: /proc/sys/net/ipv4/ip_forward: Keine Berechtigung
Hmm, das ist komisch, das sollte gehen. Was zeigt denn ein
ls -l /proc/sys/net/ipv4/ip_forward
Die Zeile sollte anfangen mit -rw-r--r-- 1 root root.
Du kannst übrigens für die Arbeiten auch dauerhaft eine Rootshell nutzen, wenn Du einmal
sudo su -
absetzt. Dann bist Du innerhalb dieses Terminalfensters Superuser und kannst Dir die einzelnen sudos sparen. MIt exit wirst Du wieder normaler User.
Vielleicht hilfts weiter.
Gruss- Georg B. aus H.
-
Hi,
Hoffentlich ist's nicht unhöflich, wenn ich mich da einmische- ich liebe nur Linux-Probleme:
Schön, daß es Leute wie Dich gibt, Probleme mag ich nämlich gar nicht (egal auf
welchem System. :)
Mit
sudo lsmod | lessist iptable_nat in der Liste vorhanden, Size 3543, used by 1.
Hmm, das ist komisch, das sollte gehen. Was zeigt denn ein
ls -l /proc/sys/net/ipv4/ip_forward
Die Zeile sollte anfangen mit -rw-r--r-- 1 root root.
Genau so sieht es aus! Dateigröße allerdings 0 Byte.
Gruß,
Latz
-
Schön, daß es Leute wie Dich gibt, Probleme mag ich nämlich gar nicht (egal auf
welchem System. :)
Ooch, komm- dann wär's doch langweilig ;D
Aber mal ernsthaft: Hätte ich gleich nachgedacht, statt nur blind zu zitieren, wärst Du schon weiter. Ein "sudo echo" kann nämlich niemals funktionieren. "sudo" ruft ein Programm mit Superuser-Rechten auf. "echo" ist aber kein Programm, sondern ein Befehl innerhalb der Shell (meist die bash). Du musst also entweder wie oben gesagt mit sudo su - eine Superuser-Shell aufmachen oder Du verwendest:
sudo bash -c "echo 1 > /proc/sys/net/ipv4/ip_forward"
(Anführungszeichen sind wichtig!). Ich bevorzuge persönlich eine Superuser-Shell; meist muss man ja doch mehr als ein Kommando als root absetzen... .
Die Länge von 0 Bytes ist übrigens OK. Dateien in /proc sind ja keine echten Dateien, sondern nur Schnittstellen zu Speicherstellen und Funktionen des Kernels. Da wird selten eine Grösse mit angegeben.
Gruss- Georg B. aus H.
-
Hoffentlich ist's nicht unhöflich, wenn ich mich da einmische
Ganz im Gegenteil, besser hätte ich es definitv nicht erklären können =)
-
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
-
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.
-
Hi,
das scheint ja so als kämen wir der Sache doch noch auf die Spur...
Mit
curl --limit-rate 10K <URL> -o outfilelief 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
-
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,...
-
zwecks mtu und so ist hier (http://forum.atari-home.de/index.php?topic=1755.msg7185#msg7185) vielleicht noch ne info dabei..
-
Hi,
@m0n0: Auch wenn ich nicht mag werde ich es wohl tun (dieses WE).
@afalc060: Danke für den Tipp, aber es funzt mit StinG ja einwandfrei
(StinG benutzte ich schon seit Modem-Zeiten mit TOS oder MagiC, da kenn'
ich mich aus). Leider sind nicht alle Einstellungen direkt auf MiNT zu
übertragen.
Gruß,
Latz
-
so wie ich jetzt gerade eben erst geoeilt habe, gibt es gar keinen open source treiber in dem man was fixenkoennte,... :-(
geht evt. Noch im tcp stack, aber allgemein waere es sinnvoll die ethernec sourcen ins fremint cvs zu bekommen...
-
so wie ich jetzt gerade eben erst geoeilt habe, gibt es gar keinen open source treiber in dem man was fixenkoennte,... :-(
geht evt. Noch im tcp stack, aber allgemein waere es sinnvoll die ethernec sourcen ins fremint cvs zu bekommen...
Ist nicht ganz richtig, unter http://home.arcor.de/thomas.redelberger/prj/atari/etherne/index.htm
sind sourcen zu finden.
-
Hi,
habe jetzt zwei Durchgänge gemacht, einmal mit MTU=500 und dann mit MTU=1000: Bei beiden kam der Transfer-Abbruch recht früh.
Die sniffer-logs kann ich noch nicht hochladen, irgendwie gibt´s wohl Server-Probleme. Hole das aber sobald wie möglich nach und sage dann Bescheid.
Gruß,
Latz
-
Hallo m0n0,
hast ´ne PM.
Habe ich in der PM glatt vergessen: Treiber sind entweder ne2kenec.xif von assemsoft.atari.org oder enec6.xif aus dem CT60 Archiv o. von newTOSworld.de.
Der ne2kenec läuft (gefühlt) ein wenig besser.
Gruß,
Latz