Hallo Michael, mit wieviel Ticks/s hast du getestet? Standardeinstellung 50? Dann sollte auch mit dem neuen Timer Framework das gleiche rauskommen. Dreh doch bitte mal die "Periodic ticks per second" hoch, Größenordnung 500 Hz oder mehr, und wiederhole den Test.
VG michaelb Am 22.10.2015 um 23:16 schrieb Michael Späth: > 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 Brakemeier mich...@brakemeier.de _______________________________________________ Ethersex-devel mailing list Ethersex-devel@list.zerties.org http://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel
