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

[Latz]

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

[afalc060]

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?

[Latz]

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

[m0n0]

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

[Latz]

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

[m0n0]

Ja bitte, ich setze 0,10€ das es mit dem uMiNT kernel geht!

[Latz]

Bitte überweise 0.10 Euro auf mein Konto Nr....
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

[m0n0]

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....

[m0n0]

NOCH WAS 

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.

[Latz]

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

[Latz]

Hallo,
hier die Testergebnisse (freemint 1-17-0 und 1-18-cur):

Code: [Auswählen]

curl http://www.fairlite.demon.co.uk/FreeMiNT/builds/freemint/trunk-26072011.tar.bz2 -o /tmp/testrunk.zip --trace error.logund

Code: [Auswählen]

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

Code: [Auswählen]

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

[m0n0]

Wieso, wenn die Dateien vollständig geladen werden, dann ist doch alles OK 

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.

[Latz]

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

Code: [Auswählen]

curl -v <http://langedatei.zip>und wie weiter?

Dank und Gruß,
Latz

[Latz]

OK, das error.log von curl findet sich hier:
http://latzmaster.kabelhomepage.de/fotoalbum/fotoalbum_detail.asp?selectedMediaID=1&selectedAlID=1&mediatype=textfile
Bitte .pdf in .zip umbenennen.

Latz

[m0n0]

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....

[Latz]

Hi,
Ausgabe in Datei: Aaargh, das war wohl zu einfach für meinen hochentwickelten Intellekt 
Ok, hier curl_output.pdf (bitte wieder in .zip umbenennen)
finden sich drei Ausgaben mit

Code: [Auswählen]

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

[m0n0]

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

[Latz]

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
Aber ich habe nochmal zwei Testläufe mit

Code: [Auswählen]

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
Gruß,
Latz

[m0n0]

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....

[Latz]

Hi,
in der Tat, es ist reproduzierbar:

Code: [Auswählen]

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