Hallo!
>> YPort drops incoming packets (Host -> EtherSex) when they are sent too fast.
> [...]
>
> Bist Du sicher, dass Ethersex TCP-Pakete verwirft? Wenn es keine weiteren
> Daten empfangen kann, sollte das TCP-Receive-Windows auf Null gehen.
Hier der Wireshark Mitschnitt, zweimal wird 12345 gesendet, zweimal empfangen,
zweimal geackt, das dritte Mal verschwindet es im Nirwana (No. 13 ist das
dritte Paket, No. 14 der Ack, aber es kommt einfach nix mehr zurück...)
Ich habe es mehrfach wiederholt, es sind immer exakt diese Pakete...
Erhöhe ich den Delay zwischen Paketen auf ca. 35msec dann gehen alle ohne
Verlust raus...
(69 ist der EtherSex Knoten, 81 ein Ubuntu Host):
No. Time Source Destination Protocol
Length Info
3 2.411121000 192.168.178.81 192.168.178.69 TCP 74
42582 > 7970 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=844640
TSecr=0 WS=128
No. Time Source Destination Protocol
Length Info
4 2.412610000 192.168.178.69 192.168.178.81 TCP 60
7970 > 42582 [SYN, ACK] Seq=0 Ack=1 Win=330 Len=0 MSS=330
No. Time Source Destination Protocol
Length Info
5 2.412673000 192.168.178.81 192.168.178.69 TCP 54
42582 > 7970 [ACK] Seq=1 Ack=1 Win=29200 Len=0
No. Time Source Destination Protocol
Length Info
6 2.412771000 192.168.178.81 192.168.178.69 TCP 59
42582 > 7970 [PSH, ACK] Seq=1 Ack=1 Win=29200 Len=5
Data: 3132333435
[Length: 5]
No. Time Source Destination Protocol
Length Info
7 2.414668000 192.168.178.69 192.168.178.81 TCP 60
[TCP ZeroWindow] 7970 > 42582 [ACK] Seq=1 Ack=6 Win=0 Len=0
No. Time Source Destination Protocol
Length Info
8 2.423967000 192.168.178.69 192.168.178.81 TCP 60
7970 > 42582 [PSH, ACK] Seq=1 Ack=6 Win=255 Len=5
Data: 3132333435
[Length: 5]
No. Time Source Destination Protocol
Length Info
9 2.424096000 192.168.178.81 192.168.178.69 TCP 54
42582 > 7970 [ACK] Seq=6 Ack=6 Win=29200 Len=0
No. Time Source Destination Protocol
Length Info
10 2.424328000 192.168.178.81 192.168.178.69 TCP 59
42582 > 7970 [PSH, ACK] Seq=6 Ack=6 Win=29200 Len=5
Data: 3132333435
[Length: 5]
No. Time Source Destination Protocol
Length Info
11 2.426127000 192.168.178.69 192.168.178.81 TCP 60
[TCP ZeroWindow] 7970 > 42582 [ACK] Seq=6 Ack=11 Win=0 Len=0
No. Time Source Destination Protocol
Length Info
12 2.443925000 192.168.178.69 192.168.178.81 TCP 60
7970 > 42582 [PSH, ACK] Seq=6 Ack=11 Win=255 Len=5
Data: 3132333435
[Length: 5]
No. Time Source Destination Protocol
Length Info
13 2.444213000 192.168.178.81 192.168.178.69 TCP 59
42582 > 7970 [PSH, ACK] Seq=11 Ack=11 Win=29200 Len=5
Data: 3132333435
[Length: 5]
No. Time Source Destination Protocol
Length Info
14 2.445596000 192.168.178.69 192.168.178.81 TCP 60
7970 > 42582 [ACK] Seq=11 Ack=16 Win=255 Len=0
> Völlig korrekt. Ethersex´ Zeitscheibe ist 20ms. Du könntest mal den Branch
> new_timer_framework testen. Der zeigt ein deutlich besseres Zeitverhalten.
Habe ich getestet, passiert das gleiche. Oben ist das Ergebnis dieses Branches.
Ich habe auch den Hop über meinen Gigabit Switch mal eliminiert und direkt
angeklemmt -> das gleiche Verhalten.
Hat jemand ne Idee wie ich das eventuell anders testen kann? Gibt es dafür
Testskripte?
--
Michael
_______________________________________________
Ethersex-devel mailing list
Ethersex-devel@list.zerties.org
http://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel
