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.
Ok, habe ich gemacht (500): Es ändert sich garnichts. Wenn ich nicht
ziemlich genau 40msec zwischen den Requests warte droppt er die Pakete.
Zusätzlich habe ich eine andere Linux Distro probiert - absolut gleicher
Effekt.
Um Python auszuschließen habe ich den Test in C geschrieben - exakt
gleiches Resultat. Zwei Pakete gehen durch, drittes wurde gedroppt.
Und zum Schluß habe ich alles noch wiederholt mit einer zweiten Hardware
- einem Pollin NetIO (mit Original MEGA32) - der *exakt* das gleiche
Phänomen zeigt. Ich glaube jetzt habe ich restlos alles ausgeschlossen:
Branches, Client OS, Hardware und Client Software.
Zusätzlich habe ich noch andere Tests gefahren: Wenn ich die serielle
Schnittstelle zu mache nach einem Send/Receive, dann kann ich mit
beliebiger Speed das tun. Nur wenn ich sie offen lasse, dann passiert das.
Außerdem kann ich per ECMD auf Port 2701 auch mit beliebiger Speed
Kommandos absetzen: Alle kommen an und werden umgesetzt (Durschnittliche
Zeit: 2,4msec bei meinen Tests - also deutlich schneller als 40msec).
Ich habe auch ein bisschen gestöbert in yport*.c und habe die Funktion
yport_rxstart gefunden, die im zweiten if Teil gar kein ISR Lock macht -
damit könnte doch theoretisch die Interruptroutine Daten falsch senden
während dem memmove?
Ich habe mal einen provisorischen semlock drum gebastelt -> hat aber nix
geholfen. Denke, der Fall wird auch nur sehr selten passieren.
Aber genau dieser Teil müsste bei mir benutzt werden: Ich schreibe ja so
schnell, dass er dort umkopieren muss weil er vorher noch nicht fertig
ist, aber schon ein paar Bytes gesendet hat.
Ich bin ratlos und kurz davor, das YPort von Ethersex mit uip selbst
nach zu schreiben... :-( Bringt mir aber auch nicht viel, ich brauche
auch den Rest von EtherSex...
--
Michael
_______________________________________________
Ethersex-devel mailing list
Ethersex-devel@list.zerties.org
http://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel
