Re: [ethersex-devel] Problem with YPort

[Bastian Bittorf]

* Michael Späth  [26.10.2015 07:11]:
> Gefunden habe ich den Fehler übrigens weil ich mir den Code vom Telnet und 
> I2C Slave Protocol angeguckt habe... da ist übrigens richtig ;-)

Danke! bye, bastian

___
Ethersex-devel mailing list
Ethersex-devel@list.zerties.org
http://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel

Re: [ethersex-devel] Problem with YPort

[Michael Späth]

Hi!

> Habe weitere Tests gemacht: yport_rxstart wird erst gar nicht aufgerufen 
> beim Empfangen des dritten Paketes (habe einen Counter mitlaufen lassen 
> den ich in die ersten 4 Bytes jedes Antwort Paketes reingefummelt habe...)
> 
> D.h. uip_newdata() liefert 0 beim dritten Paket... habe das auch mal 
> debugged, und ja, es wird wirklich beim dritten Paket nicht aktiv (und 
> beim fünften, siebten, usw...)

Ich habs gefixt. Es läuft nun alles wie gewünscht und sehr flott: 1.97msec für 
4 bytes, keine drops.

Würde mich freuen wenn es jemand eincheckt, bin noch nicht so fit mit git (oder 
es mir kurz erklärt wie ich ein request mache, würde mich auch freuen).

(Fehler war: else if (uip_newdata()) übersprang einfach die neuen Daten wenn 
gleichzeitig ein anderes Event war (z.B. ACK von gesendeten Daten - was damit 
nix zu tun hat!!!))

Ich denke, das ist nie aufgefallen weil es nur passiert wenn im exakt gleichen 
Moment Daten ankommen und geschickt werden (loopback oder sehr schnelles 
Protokoll).

Gefunden habe ich den Fehler übrigens weil ich mir den Code vom Telnet und I2C 
Slave Protocol angeguckt habe... da ist übrigens richtig ;-)


Ach ja, hier ist es eventuell auch falsch:


protocols/ems/ems_net.c:  } else if (uip_newdata()) {
protocols/modbus/modbus_net.c:  } else if (uip_newdata()) {
protocols/mqtt/mqtt.c:  else if (uip_newdata() && uip_len) {
protocols/irc/irc.c:else if (uip_newdata() && uip_len) {
protocols/bsbport/bsbport_net.c:  else if (uip_newdata())

MQTT und ModBus gucke ich mir später eventuell noch an, da ich die selbst in 
meinem Haus als Bus verwende und dafür auch den EtherSex testen wollte. Aber 
ich denke "else" dort überall wegzunehmen sollte ok sein...



diff --git a/protocols/yport/yport_net.c b/protocols/yport/yport_net.c
index 6eb27a8..a1a10cf 100755
--- a/protocols/yport/yport_net.c
+++ b/protocols/yport/yport_net.c
@@ -85,8 +85,10 @@ yport_net_main(void)
 if (yport_conn == uip_conn)
   yport_conn = NULL;
   }
-  else if (uip_newdata())
+  
+  if (uip_newdata())
   {
+
 if (uip_len <= YPORT_BUFFER_LEN &&
 yport_rxstart(uip_appdata, uip_len) != 0)
 {



-- 
Michael

___
Ethersex-devel mailing list
Ethersex-devel@list.zerties.org
http://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel

Re: [ethersex-devel] Problem with YPort

[Michael Späth]

Hi!

Habe weitere Tests gemacht: yport_rxstart wird erst gar nicht aufgerufen 
beim Empfangen des dritten Paketes (habe einen Counter mitlaufen lassen 
den ich in die ersten 4 Bytes jedes Antwort Paketes reingefummelt habe...)


D.h. uip_newdata() liefert 0 beim dritten Paket... habe das auch mal 
debugged, und ja, es wird wirklich beim dritten Paket nicht aktiv (und 
beim fünften, siebten, usw...)



--
Michael

___
Ethersex-devel mailing list
Ethersex-devel@list.zerties.org
http://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel

Re: [ethersex-devel] Problem with YPort

[Michael Späth]

Hi!


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.

Ändert sich was wenn du die Baudrate der seriellen Schnittstelle
veränderst?


9600 und 115200 getestet. No change.


--
Michael

___
Ethersex-devel mailing list
Ethersex-devel@list.zerties.org
http://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel

Re: [ethersex-devel] Problem with YPort

[Michael Späth]

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

Re: [ethersex-devel] Problem with YPort

[Udo1]

Am 24.10.2015 um 12:33 schrieb Michael Späth:
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. 

Ändert sich was wenn du die Baudrate der seriellen Schnittstelle veränderst?

Gruß
Udo

___
Ethersex-devel mailing list
Ethersex-devel@list.zerties.org
http://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel

Re: [ethersex-devel] Problem with YPort

[Michael Brakemeier]

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   SourceDestination   Protocol 
> Length Info
>   3 2.411121000192.168.178.81192.168.178.69TCP  
> 74 42582 > 7970 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 
> TSval=844640 TSecr=0 WS=128
>
> No. Time   SourceDestination   Protocol 
> Length Info
>   4 2.41261192.168.178.69192.168.178.81TCP  
> 60 7970 > 42582 [SYN, ACK] Seq=0 Ack=1 Win=330 Len=0 MSS=330
>
> No. Time   SourceDestination   Protocol 
> Length Info
>   5 2.412673000192.168.178.81192.168.178.69TCP  
> 54 42582 > 7970 [ACK] Seq=1 Ack=1 Win=29200 Len=0
>
> No. Time   SourceDestination   Protocol 
> Length Info
>   6 2.412771000192.168.178.81192.168.178.69TCP  
> 59 42582 > 7970 [PSH, ACK] Seq=1 Ack=1 Win=29200 Len=5
>
> Data: 3132333435
> [Length: 5]
>
> No. Time   SourceDestination   Protocol 
> Length Info
>   7 2.414668000192.168.178.69192.168.178.81TCP  
> 60 [TCP ZeroWindow] 7970 > 42582 [ACK] Seq=1 Ack=6 Win=0 Len=0
>
> No. Time   SourceDestination   Protocol 
> Length Info
>   8 2.423967000192.168.178.69192.168.178.81TCP  
> 60 7970 > 42582 [PSH, ACK] Seq=1 Ack=6 Win=255 Len=5
>
> Data: 3132333435
> [Length: 5]
>
> No. Time   SourceDestination   Protocol 
> Length Info
>   9 2.424096000192.168.178.81192.168.178.69TCP  
> 54 42582 > 7970 [ACK] Seq=6 Ack=6 Win=29200 Len=0
>
> No. Time   SourceDestination   Protocol 
> Length Info
>  10 2.424328000192.168.178.81192.168.178.69TCP  
> 59 42582 > 7970 [PSH, ACK] Seq=6 Ack=6 Win=29200 Len=5
>
> Data: 3132333435
> [Length: 5]
>
> No. Time   SourceDestination   Protocol 
> Length Info
>  11 2.426127000192.168.178.69192.168.178.81TCP  
> 60 [TCP ZeroWindow] 7970 > 42582 [ACK] Seq=6 Ack=11 Win=0 Len=0
>
> No. Time   SourceDestination   Protocol 
> Length Info
>  12 2.443925000192.168.178.69192.168.178.81TCP  
> 60 7970 > 42582 [PSH, ACK] Seq=6 Ack=11 Win=255 Len=5
>
> Data: 3132333435
> [Length: 5]
>
> No. Time   SourceDestination   Protocol 
> Length Info
>  13 2.444213000192.168.178.81192.168.178.69TCP  
> 59 42582 > 7970 [PSH, ACK] Seq=11 Ack=11 Win=29200 Len=5
>
> Data: 3132333435
> [Length: 5]
>
> No. Time   SourceDestination   Protocol 
> Length Info
>  14 2.445596000192.168.178.69192.168.178.81TCP  
> 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

Re: [ethersex-devel] Problem with YPort

[Michael Späth]

Hi!

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

Ja, bin ich. Wireshark zeigt sie an, und sie kommen weder per Loopback zurück 
noch wenn ich ein serielles Modul dranhänge zum Debuggen -> sie sind weg. 
Lustigerweise sagt mir die Netzwerk API auch sie wären ge'ACKt worden...

>> it will print exactly once 12345 and then it stalls: The reason is quite
>> simple, it runs the loop once and then the next send will NOT deliver
>> the packet. It will say so, and Wireshark also sees the packet, but
>> EtherSex somehow drops it.
> 
> Konfiguriere mal den Debug für das YPort-Modul und lass Dir die Statistik
> ausgeben. Wahrscheinlich gehen auf der USART die Zeichen verloren wegen
> Pufferüberlauf.

Habe ich natürlich auch schon gemacht, keine Überläufe. Bei 5 Bytes und 384 
Byte Puffer auch unwahrscheinlich... er stirbt ja schon beim zweiten Versuch, 5 
Bytes zu senden.

>> If you comment in the "sleep", everything works fine. I found EtherSex
>> needs at least 20-30msec between ethernet packets, otherwise it just
>> drops them (huh? it's TCP!).
> 
> Völlig korrekt. Ethersex´ Zeitscheibe ist 20ms. Du könntest mal den Branch
> new_timer_framework testen. Der zeigt ein deutlich besseres Zeitverhalten.

Das er sammelt und schickt ist ja ok... aber droppen sollte er doch nie?

new timer framework kannte ich gar nicht, habe es gerade gefunden, werde es 
heute Abend direkt testen und berichten.

> Du bist herzlich in unseren IRC-Kanal eingeladen! Adresse im WIKI.

Danke, ich schau mal vorbei!

-- 
Michael

___
Ethersex-devel mailing list
Ethersex-devel@list.zerties.org
http://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel

Re: [ethersex-devel] Problem with YPort

[eku]

Hallo Michael,

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

> it will print exactly once 12345 and then it stalls: The reason is quite
> simple, it runs the loop once and then the next send will NOT deliver
> the packet. It will say so, and Wireshark also sees the packet, but
> EtherSex somehow drops it.

Konfiguriere mal den Debug für das YPort-Modul und lass Dir die Statistik
ausgeben. Wahrscheinlich gehen auf der USART die Zeichen verloren wegen
Pufferüberlauf.

> If you comment in the "sleep", everything works fine. I found EtherSex
> needs at least 20-30msec between ethernet packets, otherwise it just
> drops them (huh? it's TCP!).

Völlig korrekt. Ethersex´ Zeitscheibe ist 20ms. Du könntest mal den Branch
new_timer_framework testen. Der zeigt ein deutlich besseres Zeitverhalten.

Du bist herzlich in unseren IRC-Kanal eingeladen! Adresse im WIKI.


___
Ethersex-devel mailing list
Ethersex-devel@list.zerties.org
http://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel

Re: [ethersex-devel] Problem mit YPort (Takt?)

[Roman Heinz]

Am 17. Oktober 2012 21:01 schrieb Roman Heinz romanhe...@web.de:
 Gibts irgendwo ein Beispiel wie man eigenen code einbindet (neues
 ECMD, Control6, cron job, ...?) und das auch noch so, dass beim
 nächsten git fetch noch alles da ist/funktioniert?

OK, ich habe was gefunden.
Ein eigenes ECMD, ausgehend vom appsample
(http://www.ethersex.de/index.php/Application_Sample_%28Deutsch%29)
scheint schonmal ein guter Anfang zu sein.

Ich würde gerne Eclipse benutzen. Das setup mit dem AVR plugin und der
toolchain funktioniert im Prinzip, zumindest für ein simples
helloworld-Projekt.

Wie importiere ich nun am besten ethersex in Eclipse?
Geht das überhaupt sinnvoll (wegen m4 etc.)?


Gruß,
Roman

___
Ethersex-devel mailing list
Ethersex-devel@list.zerties.org
https://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel

Re: [ethersex-devel] Problem mit YPort (Takt?)

[Udo1]

Am 17.10.2012 13:45, schrieb Roman Heinz:

lfuse:w:0xff
Wo könnte der Fehler noch liegen?

Wahrscheinlich schwingt dein Quarz nicht richtig. Versuch mal lfuse = 0xf7
Damit wird der Full Swing Oscillator eingeschaltet.
Ref.: http://www.engbedded.com/fusecalc

Gruß
Udo

___
Ethersex-devel mailing list
Ethersex-devel@list.zerties.org
https://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel

Re: [ethersex-devel] Problem mit YPort (Takt?)

[Roman Heinz]

 Wahrscheinlich schwingt dein Quarz nicht richtig. Versuch mal lfuse = 0xf7
 Damit wird der Full Swing Oscillator eingeschaltet.
 Ref.: http://www.engbedded.com/fusecalc

 Gruß
 Udo

Hallo Udo.
Danke für den Tip, werde ich ausprobieren, wenn ich mit folgendem
Kommando nicht weiterkomme:

avrdude -p m644p -c usbasp -u -U lfuse:w:0xFF:m -U hfuse:w:0xD9:m -U
efuse:w:0xFF:m

Ich hatte wohl ein paar Fehler in der anderen Kommandozeile (-P ohne
parameter, kein -u).
Die lfuse wurde wohl gar nicht geändert und steht immer noch auf
Auslieferungszustand, d.h. das Teil läuft mit 1MHz system clock.

Heute Abend weiß ich mehr...


Gruß

___
Ethersex-devel mailing list
Ethersex-devel@list.zerties.org
https://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel