Latenzzeit beim Schreiben eines Zustandes

[andre1000]

Moin zusammen,

in meinem Projekt ist mir aufgefallen, dass sehr lange Latenzzeiten von ca. 50ms für die Änderung eines Zustandes existieren. Ist diese Zeit Normal?

Hier ein Beispielcode in Javascript:

setState('testvariable',1);
log(getState('testvariable').val);
setTimeout(function() {log(getState('testvariable').val)},10);
setTimeout(function() {log(getState('testvariable').val)},40);
setTimeout(function() {log(getState('testvariable').val)},50);
setTimeout(function() {log(getState('testvariable').val)},60);

[paul53]

Auf meinem RasPi2 ist die Latenzzeit von setState() + getState() ca. 12 +/- 6 ms. Allerdings ist die CPU-Auslastung sehr gering.

[apollon77]

Das hängt von sehr vielen Faktoren ab. JavaScript arbeitet Asynchron und nodejs ist Single-Threaded! Es wird also quasi die Arbeit intern "gequeued" (die sog. Event-Loop) und nacheinander abgearbeitet.

Bedeutet: ein "getState" direkt nach einem "setState" wird NIEMALS den neuen Wert haben.

Wie lange es dauert hängt davon ab:

• Was die sendende Instanz (in dem Fall Javascript) so alles parallel zu tun hat.
• Was der js.controller (empfangene Instanz) es so zu tun hat weil die es dann als Subscriped Wert wieder an JavaScript Instanz raussendet
• Und damit nochmal: Was die empfangene Javascript-Instanz so zu tun (die bekommt ja im Standard ALLE State changes gesendet) hat bis der Wert aktualisiert wurde in den internen Datenstrukturen.

Weil erst danach bekommst Du mit getState den Wert (unter der Annahme du nimmst die Standardeinstellung).

[andre1000]

Hallo apollon,

danke für die Ausführug. Du meinst, ... unter Annahme der Standardeinstellungen...
Existiert ggf die Möglichkeiten durch Einstellungen hier etwas zu optimieren?

[apollon77]

Gib uns doch mal ein paar mehr Infos zu Deinem System unter berücksichtung der Themen die ich angesprochen habe

[andre1000]

Hallo,

mein Projekt ist noch ziemlich übersichtlich. Ich nutze nodered als Interface zu den Steuerungen, die per CAN angesprochen werden.
Beim Ausführen des Testscripts wurde kein weiteres Script getriggert.
Allgemein hat js.controller som um die 40 Triggerbedinungen, die jeweils mit getState und setState arbeiten. Jedoch werden von diesen Triggerbedingungen maximal 4 parallel ausgeführt.
ioBroker läuft auf einem BananaPi M1.
Ich hoffe hiermit konnte ich das System ausreichend zu beschreiben.

[apollon77]

naja die Triggerbedingungen hat nicht der controller, sondern dein node.red, korrekt? Das beispiel von oben war aber eher aus dem JavaScript Adapter.

Aber jetzt mal die Frage: Sind dir 50ms wirklich zu lang? Was hast Du als Anwendung vor wo es schneller sein muss?

in solchen Fällen würde ich sagen: Stell mal auf redis um und schaue nochmal.

[andre1000]

Hallo,
ja, es stimmt, der erste Trigger kommt von NodeRed. Nur danach habe ich mehrere js gesteuerte Zustandstrigger.
Hier mals kurz der Ablauf bei mir:

• Taster wird von Steuerung erfasst und per CAN gesendet
  Daten kommen
• von CAN über NodeRed in ioBroker
• Anaylse welcher Taster betätigt wurde
• Änderung des Zustandes in ioBroker
• Erstellen des CAN-Objektes für das Schalten
• Übertragen des Zustandes an NodeRed

All dies mach ich über Zustände. Aus diesem Grunde habe ich mit dem Zeitversatz ein paar Probleme.

[apollon77]

Ok, hast du mal Redis versucht ob es was ändert?
BananaPi ... SD Karte oder gescheiter Storage dahinter? wie geht es dem System so auslastungstechnisch ... RAM und CPU und so. WIeviel CPU braucht der js.controller im Schnitt?

[andre1000]

Redis habe ich noch nicht ausprobiert. Hier wage ich mich aktuell noch nicht ran.
Am BananaPI habe ich eine SSD Platte auf der das gesamte System läüft. Gesamtprozessorlast ('system.host.BPI-M1-ioBroker.load') liegt im Schnitt bei 85% und RAM ('system.host.BPI-M1-ioBroker.mem') bei 35% bei den Instanzen wird für den js-.controller 80MB angezeigt..
Existiert eine gute Anleitung, wie ich Redis einfach in ioBroker implementiert bekomme und im js.controller anspreche?

[Homoran]

@andre1000 sagte in Latenzzeit beim Schreiben eines Zustandes:

Redis habe ich noch nicht ausprobiert. Hier wage ich mich aktuell noch nicht ran.

Solltest du.
Das hilft sehr bei dem dual core.

@andre1000 sagte in Latenzzeit beim Schreiben eines Zustandes:

Am BananaPI habe ich eine SSD Platte auf der das gesamte System läüft. Gesamtprozessorlast ('system.host.BPI-M1-ioBroker.load') liegt im Schnitt bei 85%

Hängt die direkt am SATA oder an usb?
Letzterer würde das erklären

[apollon77]

@andre1000 Was sagt denn "top" so beim prozess js-controller ... auch 85%? Dann auf jeden Fall Redis bitte! Und dann ist das auch der grund für die Latenz. Denke es ist I/O ...

Redis: vllt hat @Homoran no e bessere Anleritung, ich hätte https://github.com/ioBroker/ioBroker.js-controller#using-redis-as-states-db

[Homoran]

@apollon77
Ich muss da mal was neu machen

Das letzte habe ich in den readme zu den neuen images geschrieben., entspricht aber dem vin dir verlinkten.

Ich bekomme hier nichts reinkopiert
Was ist das denn?

[andre1000]

Ich habe redis installiert. Nach dem ersten Test sah es wirklich super aus. Antwortzeit nach ca. 10ms. Jetzt zwei Stunden später ist die Zeit auf ca. 35ms angestiegen. Werde morgen mal das geasmte System neu starten und dann berichten.

@Homoran die SSD ist direkt am SATA Anschluss dran.