Systemstart und sendtcp()

[enertegus]

Deshalb wird es wohl der beste Weg sein, wenn ich leihweise ein Testgerät nutzen könnte und Schritt für Schritt von wenigen Joins und ohne Javascript-Module vorwärts gehe...

Klar, die Kontaktadresse hast Du.

[saft6luck]

Hat leider etwas gedauert, da ich über 2 Switches tracen muss :-(

Der Trace ist ein Ausschnitt aus dem Altag und zeigt:

• Etwas Überlapp, damit man sieht, dass der eibPC neu verbindet, die alte Verbindung war ca. eine halbe Stunde beendet.
• der CF (iPad Air) versucht den Verbindungsaufbau, der eibPC antwortet auf die erste Passwortabfrage nicht (Port 59878), nach 20 Sekunden habe ich den CF beendet und neu gestartet
• auf Anfrage 2 (Port 59880), 3 (Port 59881) und 4 (Port 59882) kommt die Antwort dann gebündelt (siehe Portwechsel und PW). Alle Antworten gehen an die richtigen Ports raus, allerdings sind die Verbindungen ja schon beendet und die 1. Antwort somit 22 Sekunden alt.

Der Fall zeigt ziemlich gut, dass die Pakete schon längst vom eibPC-Programm verschickt wurden. Sie bleiben allerdings im Puffer liegen und gehen mit teilweise erheblichen Verzögerungen raus.

Beleg hierfür ist, dass das Programm die Antwort auf die Passwortabfrage immer an den aktuellen Port der Anfrage verschickt, im Trace diese Portzuordnung aber über 20 Sekunden verzögert erscheint. Bevor die Antwort verschickt wird, gab es schon 2 weitere Anfragen auf neuen Ports.

[enertegus]

Etwas Überlapp, damit man sieht, dass der eibPC neu verbindet, die alte Verbindung war ca. eine halbe Stunde beendet.

Leider kann ich das nicht öffnen (wireshark Version 1.8.12) . Bei mir kommt da eine Meldung, dass das wireshark dieses Format nicht kennt..

Der Fall zeigt ziemlich gut, dass die Pakete schon längst vom eibPC-Programm verschickt wurden. Sie bleiben allerdings im Puffer liegen und gehen mit teilweise erheblichen Verzögerungen raus.

Ich versteh das so nicht. Meinst Du nun, der EibPC macht alles falsch oder richtig bzw. zu lange verzögert? Oder meinst Du, dass das im TCP-Puffer des EibPC hängt. Dann könnte man vielleicht auf der Linux-Ebene was tunen. Dann wäre natürlich die Frage, ab welcher Programmgröße das auftritt bzw. was genau die
Was sagt denn die Abfrage des Info-Buttons im EibStudio?

[saft6luck]

Leider kann ich das nicht öffnen (wireshark Version 1.8.12) . Bei mir kommt da eine Meldung, dass das wireshark dieses Format nicht kennt..

Mit der 1.12.2 lässt es sich aber öffnen. Einfach das neue Update installieren lassen "Help/Check for Updates"

Ich versteh das so nicht. Meinst Du nun, der EibPC macht alles falsch oder richtig bzw. zu lange verzögert? Oder meinst Du, dass das im TCP-Puffer des EibPC hängt. Dann könnte man vielleicht auf der Linux-Ebene was tunen.

Es werden 3 Anfragen (in 22 Sekunden) auf einen Schlag (nach der 3. Anfrage) beantwortet, 2 davon über Verbindungen, die nicht mehr aktiv sind. Das ist nicht gut. Am iPad geht so lange nichts, dass ist sichtbar und eben das Problem.

Der gezeigte Fall trat einmalig am Donnerstag auf, andere Verbindungsversuche waren unauffällig.

Dann wäre natürlich die Frage, ab welcher Programmgröße das auftritt bzw. was genau die

 --------------------------------------
 Objektnutzung                 | Anzahl
 ======================================
 Schaltuhr                     |     52
 Timer                         |     97
 Timebuffer                    |      0
 String Operationen            |   1686
 TCP/IP/UDP Operationen        |     46
 Stringsuche                   |    194
 Flash                         |      0
 Fliesskommaoperationen        |     78
 if/else                       |    765
 Gruppenaddressen              |    333
 KNX Busoperationen            |    317
 Stringvariablen               |    179
 Verarbeitungsobjekte          |   7012
 --------------------------------------
                         Summe |  10759

 Genutzte Objekte EibPC  16.5 %.
 Funktionen der Option NP verwendet

 EibParser wurde ohne Fehler beendet.

Mein Programm ist eher klein, kein Web-Server und auch sonst alle Überlast-Themen beseitigt. Einzig der Systemstart zickt etwas.

Was sagt denn die Abfrage des Info-Buttons im EibStudio?

IP-Adresse des EibPCs: 192.168.1.32
Firmwareversion des EibPCs: v3.012
Seriennummer des EibPCs: 00000330
Netzwerkeinstellungen: Statisch
    Netzmaske:    255.255.255.0
    Gateway:      192.168.1.1
    Nameserver 1: 192.168.1.1
    Nameserver 2: ?
    Nameserver 3: ?
Physikalische Adresse: 00-50-c2-79-31-13
Patches:
3.015.ptc
Boot image:
Boot image fixes: 0
Boot image updates: 14
System boot time: Thu Dec 18 16:56:02 CET 2014
Average CPU usage since booting: 38 %
Maximum available firmware memory: 17244 kb
VPN: The openvpn daemon is not running.
Allowed VPN users: 
EIB-Schnittstelle: EIBnet/IP (Verbindung aufgebaut)

[enertegus]

Es werden 3 Anfragen (in 22 Sekunden) auf einen Schlag (nach der 3. Anfrage) beantwortet, 2 davon über Verbindungen, die nicht mehr aktiv sind. Das ist nicht gut. Am iPad geht so lange nichts, dass ist sichtbar und eben das Problem.

Hm, das muss sich mal unser Linux Spezi nochmal anschauen. Allerdings wird das sicher nix vor dem 7.1.
Einen Anhaltspunkt, warum die beiden Anfragen verzögert rauskommen, hast Du aber nicht (aufwändige Logik mit der letzten Anfrage) etc.
Die Anfragen entstehen beim Connect, also wenn Du auf die Bedienung schaltest?

Mein Programm ist eher klein, kein Web-Server und auch sonst alle Überlast-Themen beseitigt. Einzig der Systemstart zickt etwas.

16,5% ist nun nicht gerade klein, aber sei's drum. Wenn es was hilft, können wir Dir gerne auch einen zweiten EibPC zum Testen/Abspecken schicken.

Maximum available firmware memory: 17244 kb

Das schaut eigentlich sehr gut aus. Mein Verdacht war, dass der Speicher etwas knapp wird und daher der EibPC erst umschaufeln muss, bis der TCP Server wieder gewohnt schnell läuft.

[saft6luck]

Hm, das muss sich mal unser Linux Spezi nochmal anschauen. Allerdings wird das sicher nix vor dem 7.1.

Kein Problem.

Einen Anhaltspunkt, warum die beiden Anfragen verzögert rauskommen, hast Du aber nicht (aufwändige Logik mit der letzten Anfrage) etc.
Die Anfragen entstehen beim Connect, also wenn Du auf die Bedienung schaltest?

Ich meine die Passwort-Anfrage des CFs, die Antworten darauf hängen während des "Connects". Das Makro ist da ziemlich schlank.

[highlight=epc]
//------------------------------------------------------------
//
// Password Command
//
//-------------------------------------------------------------
if (CF_Command==$p$) && change(CF_NextCommand) then {
if CF_Arg==Name_PASS then {
Name_Connected=EIN;
Name_MHeartbeat==EIN;
Name_MHeartbeat_Cycle=0u32;
// CF: send response
sendtcp(Name_Socket_Port,Name_IPC,Name_Send_OK);
// end: send response
} endif;
// generate event to process next command
CF_NextMessage_Trigger()
} endif

[/highlight]

3 mal kommt das Passwort, jeweils auf neuem Port und diese Anfragen werden alle nach dem 3. Passwort fast zeitgleich beantwortet (1 und 2 auf den alten Ports). Irgendwo klemmt es 22 Sekunden lang.

Da die Antwort ja kommt, kann es wohl nicht am Code liegen (würde ich sagen).

16,5% ist nun nicht gerade klein, aber sei's drum. Wenn es was hilft, können wir Dir gerne auch einen zweiten EibPC zum Testen/Abspecken schicken.

Wäre tatsächlich nicht schlecht, dann könnte ich den bis auf den CF abspecken.

[saft6luck]

Weitere Analysen (eher Beobachtungen) zeigen, dass der eibPC sogar später im Code vorkommende Telegramme verschickt bevor die Antwort auf die Passwortabfrage raus geht.

Scheinbar gehen die Antworten auch erst raus, wenn auf dem neuen Port keine Telegramme vom CF mehr eintreffen.

Zum Verständnis:
- Das Makro verschickt Telegramme erst, wenn sich der CF Client richtig Authentifiziert hat (Flag wird gesetzt)
-> hier wird direkt das p=ok über TCP verschickt
-> Telegramme, die hinaus gehen (bis auf die Ausnahme der Antwort auf ein falsches Passwort) zeigen also, dass der Code für die positive Antwort bereits bearbeitet wurde.
- Wird im Code z.B. sekündlich die Zeit verschickt, und dieses Telegramm erscheint auf dem aktuellen Port, wurde also das p=ok bereits "beauftragt".
- In der Kommunikation ist nun zu sehen, dass erst die Telegramme des CF Clients erscheinen, dann kommen die sekündlichen Telegramme und irgendwann dann das p=ok.
- Ein besonderes Problem scheint hier direkt nach Programmneustart aufzutreten, denn dann kommt das p=ok-Telegramm teilweise erst nach 40 und mehr Sekunden.

Meine Vermutung:
- bei TCP hat der Empfang eine höhere Priorität, als der Versand
- das erste Telegramm wird in die Sende-Schlange gestellt, die nächsten Telegramme werden dann aber sofort verschickt

[enertegus]

Weitere Analysen (eher Beobachtungen) zeigen, dass der eibPC sogar später im Code vorkommende Telegramme verschickt bevor die Antwort auf die Passwortabfrage raus geht.
- das erste Telegramm wird in die Sende-Schlange gestellt, die nächsten Telegramme werden dann aber sofort verschickt

Vieleicht wäre da eine Art Flush hilfreich. Warum ist das aber bei meinen Tests nun gar nicht aufgetreten?
Kannst Du mal testen, ob unter der Performance-Einstellung Zykluszeit erhöhen (ZB. 50 oder 100) etwas verändert?

[saft6luck]

Vieleicht wäre da eine Art Flush hilfreich. Warum ist das aber bei meinen Tests nun gar nicht aufgetreten?
Kannst Du mal testen, ob unter der Performance-Einstellung Zykluszeit erhöhen (ZB. 50 oder 100) etwas verändert?

Momentan steht sie auf 20ms. Bei 50ms bzw. 100ms wird mein restlicher Code aber sehr träge bis unbrauchbar. Testen werde ich es aber gerne.

[GoldenEye]

saft6luck, @enertegus

Ist das Thema eigentlich fertig abgehandelt?

Ich bin mit der CF-Anbindung wegen der Verzögerungen noch nicht wirklich glücklich.

G.

[saft6luck]

Ich hatte einen weiteren eibPC von Enertex geliehen bekommen und auf diesem ein reduziertes Programm für einen Test erstellt.

Zusätzlich habe ich mein JavaScript-CF-Gateway modifiziert, um eine Gegenstelle für den Test zu haben.
Beides ist nun bei Enertex, einen weiteren Kontakt hatte ich aber bisher nicht mehr.

Wegen anderer Projekte hatte ich bis jetzt aber auch kaum noch Zeit das Thema zu verfolgen.

[enertegus]

I
Wegen anderer Projekte hatte ich bis jetzt aber auch kaum noch Zeit das Thema zu verfolgen.

ich meine, Steffi hatte da noch eine Frage offen und hat mir das hingelegt Ich bin aber auch nicht so recht dazugekommen. Die Fehlerbeschreibung muss ich noch mal durchgehen, aber was ich auf den ersten Blick gelesen hatte, war mir das Verhalten auf der CF Seite nicht so ganz klar.

[saft6luck]

Evtl. können wir das ja demnächst noch einmal angehen?

[enertegus]

Ja, wobei ich ja nun in den Schwarzwald fahre und ab Montag bis Mittwoch in München bin. Donnerstag und Freitag nächste Woche sind dann Kunden im Haus, sodass es wohl 14 Tage dauern wird.

[Brick]

Ich gestehe jetzt nicht den ganzen Thread gelesen zu haben.. bei mir gibt es seit neuestem folgende Einträge, die
hier irgendwie dazu passen:

% Event: sendtcp(__IRTrans_124__iRtrans..:ERR_PROC_OBJECT_MSG_OUT@2015-04-17 16:19:10
% Event: closetcp(__IRTrans_124__iRtran..:ERR_PROC_OBJECT_MSG_OUT@2015-04-17 16:19:10
% Event: connecttcp(9090u16,192.168.178..:ERR_PROC_OBJECT_MSG_OUT@2015-04-17 16:19:11
% Event: connecttcp(PlayerX_SBPort,Play..:ERR_PROC_OBJECT_MSG_OUT@2015-04-17 16:19:11
% Event: sendtcp(__IRTrans_121__iRtrans..:ERR_PROC_OBJECT_MSG_OUT@2015-04-17 16:19:11
% Event: sendtcp(__IRTrans_121__iRtrans..:ERR_PROC_OBJECT_MSG_OUT@2015-04-17 16:19:12
% Event: closetcp(__IRTrans_121__iRtran..:ERR_PROC_OBJECT_MSG_OUT@2015-04-17 16:19:12
% Event: connecttcp(9090u16,192.168.178..:ERR_PROC_OBJECT_MSG_OUT@2015-04-17 16:19:26
% Event: connecttcp(PlayerX_SBPort,Play..:ERR_PROC_OBJECT_MSG_OUT@2015-04-17 16:19:26
% Event: connecttcp(9090u16,192.168.178..:ERR_PROC_OBJECT_MSG_OUT@2015-04-17 16:19:41
% Event: connecttcp(PlayerX_SBPort,Play..:ERR_PROC_OBJECT_MSG_OUT@2015-04-17 16:19:41
% Event: sendtcparray(DWD_Port,DWD_IP,D..:ERR_PROC_OBJECT_MSG_OUT@2015-04-17 16:19:42
% Event: connecttcp(9090u16,192.168.178..:ERR_PROC_OBJECT_MSG_OUT@2015-04-17 16:19:57
% Event: connecttcp(PlayerX_SBPort,Play..:ERR_PROC_OBJECT_MSG_OUT@2015-04-17 16:19:57

irgendwie baut er keine Verbindung mehr auf.. SB (Player Online) Macro, IRTrans Macro und DWD Macro gehen aktuell nicht...
sowohl send also auch connecttcp scheinen davon betroffen zu sein..
Und es hängt nicht am Systemstart.. also diese Einträge kommen bei mir jetzt laufend...

CF läuft bei mir übrigens nicht..

gibts einen Workaround/Lösung für das Problem ?

Gruß Martin