HMLAN: nennenswerte Abweichung zwischen msgLoadEst und Highload/Overload

[frank]

hallo martin,

vielleicht interessiert dich der folgende fall von regelmässigen highload/overload ereignissen mit den dabei aufgezeichneten msgLoadEst-werten. danach liegt msgLoadEst im schnitt 20-35 % zu hoch. siehe angehängte bilder. ausgelöst durch folgende regelmässige messages meines geflashten sw1pbu. ansonsten sollte msgloadest bei mir zwischen 8-11% liegen.

falls du deine berechnung etwas modifizieren möchtest, könnte ich noch ein paar versuche starten.

Code Auswählen Erweitern

2014.03.21 08:21:58.421 0: HMLAN_Parse: HMLAN1 R:E266EA5   stat:0000 t:081B2F33 d:FF r:FFCC     m:51 A410 266EA5 123ABC 0604000000
2014.03.21 08:22:00.527 0: HMLAN_Parse: HMLAN1 R:E266EA5   stat:0000 t:081B376D d:FF r:FFCD     m:52 A410 266EA5 123ABC 0604000000
2014.03.21 08:22:01.229 0: HMLAN_Parse: HMLAN1 R:E266EA5   stat:0000 t:081B3A2B d:FF r:FFCD     m:53 805E 266EA5 123ABC 00000000000000D6000000
2014.03.21 08:22:02.463 0: HMLAN_Parse: HMLAN1 R:E266EA5   stat:0000 t:081B3EFE d:FF r:FFCC     m:54 A410 266EA5 123ABC 0604000000
2014.03.21 08:22:03.688 0: HMLAN_Parse: HMLAN1 R:E266EA5   stat:0000 t:081B43C7 d:FF r:FFCD     m:55 A410 266EA5 123ABC 0604000000
2014.03.21 08:22:04.948 0: HMLAN_Parse: HMLAN1 R:E266EA5   stat:0000 t:081B48B3 d:FF r:FFCD     m:56 A410 266EA5 123ABC 0604000000
2014.03.21 08:22:07.368 0: HMLAN_Parse: HMLAN1 R:E266EA5   stat:0000 t:081B5227 d:FF r:FFCD     m:57 A410 266EA5 123ABC 0604000000
2014.03.21 08:22:09.145 0: HMLAN_Parse: HMLAN1 R:E266EA5   stat:0000 t:081B5919 d:FF r:FFCC     m:58 A410 266EA5 123ABC 0604000000
2014.03.21 08:22:11.269 0: HMLAN_Parse: HMLAN1 R:E266EA5   stat:0000 t:081B6165 d:FF r:FFCD     m:59 A410 266EA5 123ABC 0604000000
2014.03.21 08:22:12.566 0: HMLAN_Parse: HMLAN1 R:E266EA5   stat:0000 t:081B6676 d:FF r:FFCC     m:5A A410 266EA5 123ABC 0604000000
2014.03.21 08:22:14.280 0: HMLAN_Parse: HMLAN1 R:E266EA5   stat:0000 t:081B6D28 d:FF r:FFCD     m:5B A410 266EA5 123ABC 0604000000
2014.03.21 08:22:15.989 0: HMLAN_Parse: HMLAN1 R:E266EA5   stat:0000 t:081B73D5 d:FF r:FFCC     m:5C A410 266EA5 123ABC 0604000000
2014.03.21 08:22:17.947 0: HMLAN_Parse: HMLAN1 R:E266EA5   stat:0000 t:081B7B7C d:FF r:FFCC     m:5D A410 266EA5 123ABC 0604000000
2014.03.21 08:22:19.529 0: HMLAN_Parse: HMLAN1 R:E266EA5   stat:0000 t:081B81AA d:FF r:FFCC     m:5E A410 266EA5 123ABC 0604000000
2014.03.21 08:22:22.474 0: HMLAN_Parse: HMLAN1 R:E266EA5   stat:0000 t:081B8D2A d:FF r:FFCD     m:5F A410 266EA5 123ABC 0604000000
2014.03.21 08:22:24.322 0: HMLAN_Parse: HMLAN1 R:E266EA5   stat:0000 t:081B9463 d:FF r:FFCD     m:60 A410 266EA5 123ABC 0604000000
2014.03.21 08:22:25.999 0: HMLAN_Parse: HMLAN1 R:E266EA5   stat:0000 t:081B9AF1 d:FF r:FFCD     m:61 A410 266EA5 123ABC 0604000000
2014.03.21 08:22:27.700 0: HMLAN_Parse: HMLAN1 R:E266EA5   stat:0000 t:081BA195 d:FF r:FFCD     m:62 A410 266EA5 123ABC 0604000000
2014.03.21 08:22:29.675 0: HMLAN_Parse: HMLAN1 R:E266EA5   stat:0000 t:081BA94E d:FF r:FFCD     m:63 A410 266EA5 123ABC 0604000000
2014.03.21 08:22:30.968 0: HMLAN_Parse: HMLAN1 R:E266EA5   stat:0000 t:081BAE59 d:FF r:FFCD     m:64 805E 266EA5 123ABC 00000000000000EC000000
2014.03.21 08:22:32.782 0: HMLAN_Parse: HMLAN1 R:E266EA5   stat:0000 t:081BB572 d:FF r:FFCD     m:65 A410 266EA5 123ABC 0604000000
2014.03.21 08:22:34.752 0: HMLAN_Parse: HMLAN1 R:E266EA5   stat:0000 t:081BBD24 d:FF r:FFCD     m:66 A410 266EA5 123ABC 0604000000

gruss frank

[martinp876]

ja, interessiert mich.
DeinAufbau ist also , dass HMLAN ausschliesslich ACKs senden muss - korrekt?

Ich werden einmal ein paar tests machen

[frank]

DeinAufbau ist also , dass HMLAN ausschliesslich ACKs senden muss - korrekt?

nein.
mein normaler hmlan-traffic beruht hauptsächlich auf 5x virtueller tc + 4x virtueller vd. die erzeugen einen msgloadest von 8-11% (min,max), wenn die vd konstant sind.
die modulation der max werte aus den bildern entpricht meinem normalem verlauf.

die könnte ich doch aber mal abstellen über nacht. am besten auf ignore setzen oder?
die vvd kann ich auf dummy setzen, dann kommen dort auch ack´s.

gruss frank

[martinp876]

Hallo Frank,

ich denke mir ist die Abweichung klar. Es ist die Länge der Messages. In deinem Log sehe ich nur ACKs, die sind sehr kurz. Im Mittel ist das nicht realistisch... denke ich.

Eine genauere Berechnung müsste die Länge mit einbeziehen. werde ich einmal testen, wie man das hin bekommt.
Übrigens ignorieren ich auch die AES message.

Nicht berücksichtigen kann man gelegentliche wiederholer.... nur wenn es gescheitert ist, kann ich es rechnen.

Gruss Martin

[martinp876]

so - gerade eingecheckt, Version 5278 berücksichtigt die MessageLänge.

Immer noch nicht dabei: AES messages.

[frank]

hallo martin,

ich habe die version mal getestet. anbei der plot.

über stunden hatte ich wie gewohnt ca 10% traffic. dann um 11.25 das update eingespielt und mit shutdown restart gestartet. um eine markierung zu haben noch den blauen peak bei shutdown eingebaut. also ein zweiten restart.

gegeüber vorher sind keine weiteren aktionen dazugekommen.

eigentlich hätte ich sogar eine reduzierung erwartet, da der hmlan meinen tc ebenfalls meistens mit kurzen ack antwortet. nun das. würde ich nun noch das msgreduce der virtuellen tc auf null stellen, müssten sich werte von über 150% ergeben.
irgendwas ist faul.

gruss frank

ps: gab es nicht früher mal ein "HMLAN:cond: init" nach restart. im augenblick kann man über condition keinen shutdown restart erkennen.

[Sailor]

Hallo Frank,

Ich habe eine Bitte:
Magst uns deine kompletten Codeschnippsel ueberlassen, die letztendlich zu dem plot hinsichtlich der prozentualen Sendeauslastung des HMLANs gefuehrt hat. (1% - Regel Ueberwachung)

Ich habe auch deine Beitraege unter:  http://forum.fhem.de/index.php/topic,19892.msg135026.html#msg135026 zwar gelesen, aber irgendwie werde ich daraus nicht schlau.

Quasi: Was brauche ich in der fhem.cfg, myUtils.pm und .plot - Datei um zu den plot zu kommen den du oben in deinem Beitrag gepostet hast.
Vielleicht ist das einen WIKI - EIntrag Wert.

Da ich in Kuerze in meinem Haus 12 Heizkoerpentile + 10 Thermostate + 10 Fenstersensoren + 9 Rauchmelder installieren moechte, wuerde ich gerne auf einen Blick sehen, wann es eng wird.

Habe heute den halben Tag damit verbracht dahingehend eine Loesung zu finden.
Nicht einmal das modul "HMinfo" hat mich weiter gebracht.

Danke fuer Deine Hilfe und wuensche Dir noch ein schoenes Wochenende falls wir uns erst ab Mo lesen
    Sailor


Gesendet von meinem iPhone mit Tapatalk

[frank]

hallo sailor,

eigentlich ganz einfach.

ich schreibe mit einem at jede minute beim hmlan ein reading, welches den wert von msgLoadEst-1hour erhält:

Code Auswählen Erweitern

define a_hmlan_internals at +*00:01:00 {\
  my $trafficStr = InternalVal("HMLAN1","msgLoadEst","???");;\
  my $trafficHour = $1 if($trafficStr =~ m/1hour:(.*)% 10min steps/);;\
  fhem("setreading HMLAN1 hmTrfHour ".$trafficHour." %" );;\
}

dadurch wird gleichzeitig ein event ausgelöst, das du nur noch loggen musst. meine fileLog definition ist:

Code Auswählen Erweitern

define FileLog_Technik_IO FileLog %L/Technik_IO-%Y.log global:.*|HMLAN1:cond:.*|HMLAN1:hmTrfHour:.*
attr FileLog_Technik_IO logtype text
attr FileLog_Technik_IO room Log


die plot definition:

Code Auswählen Erweitern

define SVG_FileLog_Technik_IO_1 SVG FileLog_Technik_IO:SVG_FileLog_Technik_IO_1:CURRENT
attr SVG_FileLog_Technik_IO_1 alias 10. hmlan
attr SVG_FileLog_Technik_IO_1 label "traffic: min [$data{min1}] - avg [$data{avg1}] - max [$data{max1}] - last [$data{currval1}] ----- [".localtime()."]"
attr SVG_FileLog_Technik_IO_1 room 90_Technik


und nun noch das gnuplotfile

Code Auswählen Erweitern

# Created by FHEM/98_SVG.pm, 2014-03-22 12:11:58
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<L1>'
set ytics "init" 6,"err" 4,"wng" 3,"?" 1,"ok" 0
set y2tics
set grid y2tics
set ylabel "condition"
set y2label "msgLoadEst % / hr"
set yrange [0:7]

#FileLog 4:HMLAN1.hmTrfHour\x3a::
#FileLog 4:HMLAN1.cond\x3a::$fld[3]=~"init"?6:$fld[3]=~"ERROR-Overload"?4:$fld[3]=~"Warning-HighLoad"?3:$fld[3]=~"ok"?0:1
#FileLog 3:global.*::$fld[2]=~"SHUTDOWN"?6:$fld[2]=~"INITIALIZED"?0:0

plot "<IN>" using 1:2 axes x1y2 title 'msgLoadEst' ls l6fill lw 1 with steps,\
     "<IN>" using 1:2 axes x1y1 title 'condition' ls l0 lw 1 with steps,\
     "<IN>" using 1:2 axes x1y1 title 'shutdown' ls l2fill lw 1 with steps

dein wunschsystem sollte dem hmlan aber keine probleme bereiten. bei der 1%-regel sind ja nur die vom hmlan gesendeten messages von bedeutung. solange er nur lauscht, um eventuell logs zu erstellen und nicht permanent etwas zum steuern oder regeln hat, also kein problem. die besagten devices werden sich ja im normalfall direkt unterhalten, ohne hmlan.

denk dran, dass du jede minute ein event auslöst, eventuell verringern. ansonsten viel spass.

gruss frank

ps:

Vielleicht ist das einen WIKI - EIntrag Wert.

meine zustimmung hast du! 

[martinp876]

ja da hat doch eine Klammer gefehlt.
Da sind ACKs als Burst gezählt worden - das gibt eine 20fachen Wert.... dummer Fehler.

Ist korrigiert - hoffenltlich stimmt es jetzt

[martinp876]

also der 'last-minute-bug' scheint draussen zu sein...
Aktuell löst der Alarm 1% zu früh aus... zumindest in meinem Fall.

Ich hoffe dass es jetzt passt - für den Normalbetrieb.
Nicht berücksichtigt werden
- wiederholen von Messages durch HMLAN, wenn es erfolgreich ist (wenn es 3-mal fehl schlägt finde ich es)
=> sollte ein geringer Anteil sein
- AES mesages, die HMLAN selbst sendet
=> könnte erheblich sein. Die kann man fangen und berechnen - habe es nur noch nicht.

die üblichen Einschränkungen, bezüglich neustart/vermuteter Neustart gelten weiter.

Init war nie weg kommt immer noch als Condition. Nach Overload kommt kein Init, nach reboot oder disconnect sollte es kommen
Gruss Martin

[frank]

hallo martin,

nach 25 minuten laufzeit sieht es gut aus. morgen werde ich den hmlan dann ein bisschen quälen.

wegen condition init:
in fhem.log gibt es einen eintrag "new condition init" oder so. ich bekomme aber kein event cond:init nach reboot. nur cond:ok. ich bin mir relativ sicher, dass das früher mal da war. also init gefolgt von ok nach reboot.

gruss frank

[frank]

.... dummer Fehler.

mein ausbilder hat mir mal unter vier augen gesagt:

wer viel macht, macht viele fehler.
wer nichts macht, macht keine fehler.

mit dem 2. satz meinte er sich selber.

du hast bestimmt noch viele fehler gut. 

gruss frank

[frank]

hi martin,

echt klasse! punktlandung. 

Code Auswählen Erweitern

2014-03-23_11:18:09 HMLAN1 hmTrfHour: 87 %
2014-03-23_11:19:09 HMLAN1 hmTrfHour: 89 %
2014-03-23_11:20:09 HMLAN1 hmTrfHour: 88 %
2014-03-23_11:20:53 HMLAN1 cond: Warning-HighLoad
2014-03-23_11:21:09 HMLAN1 hmTrfHour: 90 %
2014-03-23_11:22:09 HMLAN1 hmTrfHour: 91 %
2014-03-23_11:23:09 HMLAN1 hmTrfHour: 93 %
2014-03-23_11:24:09 HMLAN1 hmTrfHour: 95 %
2014-03-23_11:25:09 HMLAN1 hmTrfHour: 97 %
2014-03-23_11:26:09 HMLAN1 hmTrfHour: 99 %
2014-03-23_11:26:17 HMLAN1 cond: ERROR-Overload
2014-03-23_11:27:09 HMLAN1 hmTrfHour: 102 %
2014-03-23_11:28:09 HMLAN1 hmTrfHour: 105 %

gruss frank

[martinp876]

zu beachten sind natürlich
- unterschiedliche messagelängen
- burst-access
- wakeup (ich denke da gibt es keinen Unterschied)
- lacyConfig(ich denke da gibt es keinen Unterschied)

und ui - wie komme ich über 100%..... das könnte noch ein Fehler sein. Zählen muss schon über 100 gehen, aber nach ErrorOverload sollte nicht mehr gesendet werden.... dann kann der Level auch nicht mehr steigen.

[Sailor]

Hallo zusammen:

Et voila: Mein allererster WIKI - Beitrag:
http://www.fhemwiki.de/wiki/HM-CFG-LAN:_%C3%9Cberwachung_der_1%25-Regel

Mit der Bitte um konstruktive Kritik 

Sailor