[HMLAN, HMUSB] Probleme mit Overload/IO-Umschaltung durch vccu und msgLoadEst

[frank]

ich habe dem obdachlosen bit mal ein provisorisches heim spendiert und ein reading zum loggen angelegt.

Code Auswählen Erweitern

2015.06.18 13:10:27.700 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:07F8CF37 IDcnt:0009 Load:100%
2015.06.18 13:10:27.838 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:02FEF6F2 IDcnt:0016 Load:31%

werde es untersuchen ...

ein vergleich vom loadbit (grün) mit msgloadest (grau) sieht ziehmlich beeindruckend aus. bei normalem gleichmässigem traffic sind beide kurven quasi deckungsgleich. martins berechnung liegt meistens 1-2% tiefer.

(http://forum.fhem.de/index.php?action=dlattach;topic=38163.0;attach=33644;image)

dann mal eine "blind-ack"-attacke gestartet. bei erreichen von highload und overload werden die unterschiede natürlich grösser.

(http://forum.fhem.de/index.php?action=dlattach;topic=38163.0;attach=33646;image)

zum schluss noch ein vergleich von hmlan und hmusb, die von einer vccu verwaltet werden. hier erkennt man schön das umschalten des prefferedIO und die bereits angesprochenen probleme. das wieder freigeben der load bei eq3 scheint mir nicht sehr vorhersagbar zu sein. das sieht bei martin geregelter aus. daher werden die unterschiede immer grösser, aber irgendwann finden die kurven immer wieder zu einander. gegen 15.30 shutdown+restart (blau). hier bleiben die zuvor erreichten loadwerte wie erwartet gleich. kurz darauf dann ein shutdown+reboot der fritzbox an der beide io und fhem laufen. hierbei ist ganz interressant, dass dadurch zumindestens ein overload des hmusb zurückgesetzt werden kann. für den hmlan bleibt nur stecker ziehen.

(http://forum.fhem.de/index.php?action=dlattach;topic=38163.0;attach=33648;image)

[martinp876]

ja, die Werte decken sich recht gut - finde ich. Die Berechnugn war nicht so schlecht.
Dennoch werde ich es auf die Werte den IO umsetzen - klar.

Dass der HMUSB nach einem reset der FB auf null steht ist möglich. Wenn der reset kommt könnte es einen reset der USB Schnittstelle kommen - evtl mit power-down. dann wäre sicher ein neustart der Zählung zu sehen.

Die Load-anzeige ist im Log ist schon eingebaut.

[frank]

ja, die Werte decken sich recht gut - finde ich. Die Berechnugn war nicht so schlecht.
Dennoch werde ich es auf die Werte den IO umsetzen - klar.

ich denke beides hat stärken und schwächen, da es zb "totzeiten" gibt. ideal wäre eine kombination. das wird hier wohl nicht lohnen und auf kosten der performance gehen.

wünschenswert wäre aber meiner meinung nach eine zusätzliche verknüpfung des realen loadwertes zur erzeugung der bisherigen zustände highload/overload. also nicht nur die stati (02xx/04xx), die beim senden von messages gemeldet werden, zu benutzen, sondern auch den aktuellen load mit einzubeziehen. so etwa in der art:

Code Auswählen Erweitern

overload_result = ((load > 95) || overload_hmlan)?"on":"off";

dadurch würden dann auch die blind-ack highload/overload auslösen können, was bisher leider nicht möglich ist. ausserdem wären die zustände wesentlich näher an der realität, denn bisher bekommt man diese stati nur durch aktives senden von messages. wie auch in den plots zu sehen ist, gibt es zum teil erhebliche verzögerungen vom zeitpunkt der meldung load=100%, bis zur generierung des zustandes overload (rote kurve). entsprechendes gilt für highload.

der vergleich bei overload mit werten kleiner 100, wie im beispiel 95, scheint mir sinnvoll, da es mir so ausschaut, dass bei erreichen von load=100, eine art "verriegelung" stattfindet. eventuell kann man dadurch die effektive verfügbarkeit der io verlängern, obwohl ein wenig kapazität "verloren" geht.

eine userdefinierte einstellung der schwellen zum erreichen der zustände, ist nun natürlich auch denkbar. zb highload=70. dadurch hat man für bestimmte dinge vielleicht mehr vorlaufzeit. wenn es natürlich ein reading msgLoad geben wird, kann man auch mit notify ganz einfach arbeiten. 

gruss frank

[martinp876]

Natuerlich werde ich die realen werte nutzen. Nur die sind real.
Der status des hmlan ist fix von hm vorgegeben. Bei 100 haben wir overload, dann darf nicht mehr gesendet werden. Vorschrift !! Jedes device ist verpflichtet sich daran zu halten, also hat eq3 es implementiert.
Die dauer ist 1h. Wenn wieder luft ist geht der leaky bucket count runter.

Man kann das device nicht laenger am leben halten. Man kann einfach nur eine bestimmte menge senden. Wenn man nicht mehr sendet auch kein overload - aber das macht keinen sinn.

Da der wert jetzt gesichert ist werde ich ihn anzeigen. Evtl kann man einen triggerlevel einbauen, dann kann der user machen, was er will, wenn er ausloest.

[martinp876]

so, eingebaut.

msgLoadCurrent   17
msgLoadHistory   5min steps: 17/17/10/10/-/-/-/-/-/-/-/-

current ist der aktuelle Zustand
History sind die vergangenen "end-stände" nach ... 5min. Man kann also sehen, wann es wieder "Luft" gibt. Der rechte Wert wird nach den nächsten 5 min "entfernt". Man kann an den Änderunge erkennen, wieviel Freiraum (credits) wieder nachkommen.

habe gerade auf relative Werte umgestellt - das ist besser zu verstehen.