KNX Queue läuft voll

[phili]

Kurz nach dem ich gepostet habe, ändert sich dann die Situation:

20180812_edomiStatus.jpg

Interessant ist, dass die Send-Rate jetzt nur noch bei 8/s liegt, obwohl edomi ja mindestens die genannten 12 Telegramme erzeugt. Habe die Datenrate auf 8/s reduziert. Die Anzahl der Telegramme in der Queue sinkt zunächst, dann sinkt aber teilweise auch die Senderate und die Anzahl der Queue-Telegramme steigen wieder an. Bus reagiert dann wie gehabt schleppend.

20180812_edomiStatus_b.jpg

In der .ini ist die maximal zulässige Anzahl der Telegramme auf 30/s beschränkt.

[gaert]

Merkwürdig... Wie gesagt habe ich Vollgas gegeben und den Bus aus allen Rohren gequält... Allerdings mit max. 20/s in der INI - vielleicht wäre dies mal ein Ansatz?

[phili]

Auch wenn keine (kaum noch) neuen Telegramme erzeugt werden, wird die Queue nur mit weniger als 4/s geleert. Im Monitor sehe ich Werte von 4/s, 3/s, 2/s, 1/s aber auch 0/s.

[phili]

Allerdings mit max. 20/s in der INI - vielleicht wäre dies mal ein Ansatz?

umgestellt .....

[gaert]

Die Telegrammrate in der INI ist übrigens die maximale welche - weniger geht immer, je nach Leistung Deines Systems. Wenn ich per Oszi den Bus mit z.B. 200 Telegrammen flute, geht bei mir die Queue auf ca. 150 (Peak) hoch und wird dann innerhalb weniger Sekunden abgearbeitet mit etwa 17 Telegrammen/s (in der INI sind's max. 20/s).

Die tatsächliche Senderate hängt dabei von vielen Faktoren ab:
- (momentane) Leistung des Systems
- Reaktionsgeschwindigkeit des Routers (ACK, etc.)
- Netzwerk (Telegramme werden ggf. wiederholt, wenn kein ACK des Routers innerhalb von 1s kommt)
- etc.

Die Kommunikation ist bei jedem einzelnen Telegramm ein Dialog zw. EDOMI und Router, d.h. der Router muss jedes Telegramm bestätigen und das kann u.U. auch mal bis zu 1s dauern. Dann bricht die Rate natürlich in Summa ein.

Wenn Du das KNX-Log mal anschmeisst, kommen wir der Sache evtl. auf die Schliche.

[Winni]

Also ich hatte beim Neustart schon immer Probleme mit der Queue, die nur relativ langsam abgebaut wurde.
Mit der 1.60 hänge ich nun nach 10 Minuten! immer noch bei 8, nun sind's wieder 10, will nicht weniger werden, obwohl kaum Traffic auf dem Bus ist
Edomi.jpg
12 Minuten: 6
Endlich, 14 Minuten 0!

[powell]

Bei mir geht die KNX: Queued nach einem Neustart inerhalb von 14s auf 0 zurück.
Läuft bei mir deutlich schneller als zuvor. Da hat es länger gedauert.

[gaert]

Wie gesagt: KNX-Log anwerfen und berichten - alles andere ist nur raten...

[Winni]

Ich hab' das LOG mal angehängt, evtl. kann mir jemand einen Tipp geben. Hat auch diesmal "nur" 7 Minuten gedauert.

Danke

[gaert]

Du fragst offenbar ca. 360 GAs ab und dies dauert rund 2,5 Minuten - nicht gerade schnell, aber auf Deinem Bus ist ja zwischendurch noch ne Menge los.

Wie kommst Du auf 7 Minuten? Also was genau dauert 7 Minuten?

Der letzte "response" auf einen Read-request kommt um 20:47:50, der erste bei 20:45:20. Alles nach 20:47:50 hat zumindest mit dem InitScan nichts zu tun...

[Winni]

7 Minuten bis die Queue als leer angezeigt wird, soweit habe ich das Log mitgeschnitten.
Dass das Init Scan so lange dauert ist ja ok, aber für die letzten 30 Einträge gehen Minuten drauf, und das versteh ich nicht, das war früher nie oder nur selten der Fall

Stehen in der Queue nur ausgehende oder auch eingehende Werte?

[vento66]

Die Frage ist ja eher welche Racingconditions dafür sorgen, das die Werte überhaupt im Queue landen. Mein Bus ist Absichtlich mit Telegrammen belastet, unter 5-7 Tps ist da selten was los. Jetzt habe ich am IP Router 2x Edomi plus Wiregate Homebridge und MQTT hängen (Ich glaube 2 Homeserver sind aktuell auch noch dran). Den Queue bekomme ich totzdem nocht voll.Selten, das mal 1 Telegramm da drinn landet.

[powell]

Ich hatte bei mir das Problem als ich zu viele Messwerte(Strom, Durchfluss Wasser,..)über den Bus gesendet hatte.
Dies hab ich nun soweit es geht minimiert. Das hat bei mir viel gebracht, seitdem läuft edomi auch viel stabiler.

Nur wie oben schon geschrieben den Punkt mit den Datenarchiven muss ich noch irgendwie hinbekommen. Viele Diagramme in der Visu sind ja schön, aber wenn diese alles verlangsamen ist es nicht vorteilhaft.

Auf alle Fälle lädt bei mir die Visu auch deutlich schneller seit Update auf 1.60.
Vielen Dank nochmal dafür, edomi ist einfach genial!

[powell]

Noch eine Frage, was bedeuten den die beiden im Screenshot mit rot eingezeichneten Felder? Diese werden bei mir recht lange abgearbeitet und erst danach läuft bzw. reagiert dann alles.

[gaert]

Das ist eine Queue für diverse Prozesse, z.B. Kamerbildarchivierung, IR-Befehle, HTTP-Befehle, Backups, etc.
Wenn beim EDOMI-Start diese Queue lange braucht, ist vermutlich das "Aufräumen" daran schuld: Große Datenbanken (Archive) oder viele Kamerabilder brauchen u.U. einige Zeit, bis z.B. alte Einträge gelöscht wurden usw.

Sollte im System-Log eigentlich zu beobachten sein...