Hallo zusammen Ich entwickle zur Zeit eine Ansteuerung für den W5100, die aus einer Zustandsmaschine auf einem FPGA besteht. Es ist sozusagen eine Implementierung des Servermodels aus dem Datenblatt. Ich bin soweit, dass ich vom PC aus verbinden und Daten übertragen kann (TCP), jedoch ist die Übertragung sehr unzuverlässig. Die Daten gehen auf dem FPGA in ein FIFO und werden zurück zum PC geschickt. Häufig kriege ich die gleiche anzahl Bytes zurück wie ich sende, aber nicht immer. Und falls die Anzahl gleich ist, sind die Werte meistens zu einem Teil falsch. Wenn ich einen grösseren Datenblock übertrage (~100k) kann es gar passieren das der W5100 sich 'aufhängt'. Ich habe auch mal das Programm Wireshark ausprobiert, um die Pakete anzusehen. Irgendwie kommen vom W5100 nur dup ack Pakete, ist das normal? Ausserdem kommen zehntausende von diesen Paketen, selbst wenn ich nur 10 Bytes übertrage. Das ergibt doch keinen Sinn? Hat hier jemand mal einen W5100 erfolgreich zum laufen gebracht, und weiss was man dabei beachten muss? Es muss doch irgendwie möglich sein. Gruss Stefan
Ich habe zumindest den älteren der Wiznets bereits erfolgreich am Controller getestet, wie der hiess habe ich grad nicht im Kopf. Was dir allerdings begegnen kann: Wenn die Parameter so gesetzt sind, dass im Transmit-Buffer keine 2 Frames Platz finden, dann werden Frames grundsätzlich zweimal hintereinander gesendet. Auf diese Weise vermeidet Wiznet das bei Minimal-Stacks sonst verbreitete Problem mit verzögerten Acks und entsprechend saumässigem Duchsatz.
Für dup acks gibt es mehrere Gründe: Paket verloren, Out-of-Order Paket erhalten, Window resizing. Wenn die nicht aufhören (ein paar sind ok), dann stimmt entweder was mit der Übertragung als solches nicht oder die TCP/IP Implementierung auf einer der beiden Seiten (vermutlich auf deiner im FPGA) hat eine Macke (verwechseln von out-of-order Paketen mit verlorenen Paketen, window size wird nicht angepasst (die TCP/IP Version von Flow-Control), etc.). Also: Fleißig Grundlagen von TCP/IP lernen, weiter Wireshark quälen und Software debuggen.
Danke für eure Antworten. @A. K.: Ich verstehe nicht ganz was du meinst. Wenn ich über den W5100 Daten verschicke, lese ich zuerst aus wieviel Platz im TX Buffer frei ist. Dann schreibe ich maximal soviel rein, update den Pointer und gebe den SEND-Befehl. Das was ich reinschreibe hat immer Platz. Wo kommt hier die Framegrösse ins Spiel? @Norgan: Das TCP/IP Zeug ist in Hardware im W5100 drin. Darauf habe ich keinen Einfluss. Der FPGA liest/schreibt nur die Register des ICs.
Stefan schrieb: > @A. K.: Ich verstehe nicht ganz was du meinst. Wenn ich über den W5100 > Daten verschicke, lese ich zuerst aus wieviel Platz im TX Buffer frei > ist. Dann schreibe ich maximal soviel rein, update den Pointer und gebe > den SEND-Befehl. Das was ich reinschreibe hat immer Platz. Wo kommt hier > die Framegrösse ins Spiel? Das ist eine Eigenheit heutiger TCP/IP-Stacks, egal ob Windows oder Linux. Der Empfänger sendet seinen Ack nicht sofort nach jedem Frame, sondern nur bei jedem zweiten Frame oder nach einem Timeout. Der Sender muss einen TCP-Frame bzw. dessen Daten aber solange aufbewahren, bis er das Ack hat. Wenn in den Puffer nur ein Frame reinpasst und sonst nichts dagegen unternommen wird, dann ist der Durchsatz folglich saumässig schlecht, weil nach jedem Frame ein paar Zehntelsekunden vergehen. Beispiel: µIP in üblicher Konfiguration. Wenn in den Wiznet 2 Frames reinpassen, dann ist alles in Ordnung. Wenn nicht, dann sendet er den Frame zweimal direkt hintereinander. Das bringt den Empfänger dazu, von einem möglichen Übertragungsproblem auszugehen und das Ack sofort zu senden. Das lastet zwar das Netz höher aus, aber der Durchsatz ist nun akzeptabel.
> Das ist eine Eigenheit heutiger TCP/IP-Stacks, egal ob Windows oder > Linux. Der Empfänger sendet seinen Ack nicht sofort nach jedem Frame, > sondern nur bei jedem zweiten Frame oder nach einem Timeout. Der Sender > muss einen TCP-Frame aber solange aufbewahren, bis er das Ack hat. > Wenn in den Puffer aber nur ein Frame reinpasst und sonst nichts dagegen > unternommen wird, dann ist der Durchsatz folglich saumässig schlecht, > weil nach jedem Frame ein paar Zehntelsekunden vergehen. Beispiel: µIP > in üblicher Konfiguration. > Wenn in den Wiznet 2 Frames reinpassen, dann ist alles in Ordnung. Wenn > nicht, dann sendet er den Frame zweimal direkt hintereinander. Das > bringt den Empfänger dazu, von einem möglichen Übertragungsproblem > auszugehen und das Ack sofort zu senden. Hmmm, okay. Danke für die Erläuterung.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.