Wiznet W5100 unzuverlässig

[Stefan (Gast)]

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

[(prx) A. K. (prx)]

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.

[Norgan (Gast)]

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.

[Stefan (Gast)]

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.

[(prx) A. K. (prx)]

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.

[Stefan (Gast)]

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