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