OWServer Abtastrate symetrisch verteilen ...

Begonnen von ritchie, 29 April 2014, 09:11:17

Vorheriges Thema - Nächstes Thema

ritchie

Hallo Zusammen,

ich habe am Wochenende mal wieder meinen 1wire Bus angesehen und hier fiel
mir auf, das sich die Abtastvorgänge alle zu einem Zeitpunkt häufen.

Besteht die Möglichkeit, das Abtasten von Werten auf die bestehende Zeitschreibe gleichmäßig zu verteilen.

Viele Grüße

R.
IPU662  Ipfire & Fhem (Homematic + MAX) - Produktiv
Cubietruck (1Wire - USB) - Produktiv

justme1968

ich hatte bei meinen letzten patches schon eingebaut das die jeweiligen OWDevices mit einer zufälligen verzögerung zwischen 0 und 20 sekunden ihre abfrage starten. das sollte den peak eigentlich schon deutlich entschärfen. hilft das bei dir nicht?

ich sehe aber gerade das das nur greift wenn man fhem neu startet. wenn man mit rereadconfig arbeitet werden alle gleichzeitig neu  gestartet. kann es sein das das dein problem ist?


ein richtiger scheduler wird fast beliebig kompliziert wenn man berücksichtig das jedes OWDevice ein eigenes abfrage intervall haben kann. ich glaube das ist nicht der richtige weg.


für meinen patch (http://forum.fhem.de/index.php/topic,16945.msg161805.html#msg161805) der die owfs abfrage inzwischen tatsächlich asynchron im hintergrund mach habe ich aber eine art warteschlange vorgesehen die nur eine bestimmte anzahl gleichzeitiger abfragen zulässt und andere wateten lässt oder sogar ganz verwirft wenn es eine anfrage für das gleiche reading schon in der warteschlange gibt. ich weiss aber noch nicht ob diese logik nicht zu viel overhead produziert und die ganzen vorteile der asynchronen verarbeitung wieder auffrisst.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

ritchie

Hi,

Zitat
ein richtiger scheduler wird fast beliebig kompliziert wenn man berücksichtig das jedes OWDevice ein eigenes abfrage intervall haben kann. ich glaube das ist nicht der richtige weg.

das glaube ich Dir.

Ich habe hierbei nur an den  Busmastern festgestellt (4 Stück), das die LED's alle immer zum gleichen Zeitpunkt aufleuchten
und bei meiner Prüfung der Events (ich habe nicht benötigte Events unterdrückt), konnte ich feststellen, das diese immer in
Blöcken auftauchen.

Ich müsste aber prüfen, welchen Patchlevel ich derzeit in meinem FHEM habe, da ich hier etwas vorsichtiger das System update. (prüfe ich abends)

Ab welchem Datum wäre den diese Funktion drin ?

Viele Grüße

R.
IPU662  Ipfire & Fhem (Homematic + MAX) - Produktiv
Cubietruck (1Wire - USB) - Produktiv

ritchie

#3
Hi,

mein System ist gepatch vom 05.03.2014. Vorhin hatte ich nach einem Neustart des Systems plötzlich eine CPU Belastung von 50-60% durch perl. Gesehen mittels "top" auf der console.
Nach  einem erneutem reboot des System liegt alles im normalen Bereich (unter 10%, manchmal kurz über 15%).


changelog sagt:
Zitat
- change:  improvements for OWDevice and OWServer (justme1968)

Gruss R.

IPU662  Ipfire & Fhem (Homematic + MAX) - Produktiv
Cubietruck (1Wire - USB) - Produktiv

ritchie

Hallo Andre,

so, jetzt habe ich ein Update des System gefahren und kann es wieder am Wochenende prüfen, ob was zu korrigieren ist.

Die LED's blinken immer noch sehr syncron.

Ich kenne es von einem anderen System (iFix) so, das man dem I/O Server für I/O-Werte einen TimeOffset für die SCAN Rate geben kann, damit diese nicht nach dem Start des System immer zum gleichen Zeitpunkt abgefragt werden. Auch könnte ich mir vorstellen, das man für die einzelen Abtasteblöcke die jeweiligen Werte mathematisch auf die Abtastung verteilt, (Anzahl der Werte / Abtastrate = Vars pro Block per Offset)

Beispiel:
Variable 1   Scanrate    5      TimeOffset   0
Variable 2   Scanrate   5      TimeOffset   1
Variable 3   Scanrate    5      TimeOffset   2
Variable 4   Scanrate    5      TimeOffset   3
Variable 5   Scanrate    5      TimeOffset   4

Hierdurch würden die einzelnen Messwerte zwar beim Systemstart etwas später aktualisiert werden, was aber in diesem Fall kein Problem
darstellt. Da ich nicht weiss, wie Ihr das intern verwaltet, wäre das ja nur eine Idee.

Wenn Bedarf ist, kann ich gerne mal ein Video der Abtastung und deren Blinkverhalten machen und Dir zur Verfügung stellen,
damit Du einen Eindruck davon bekommst.

Viele Grüße

R.






IPU662  Ipfire & Fhem (Homematic + MAX) - Produktiv
Cubietruck (1Wire - USB) - Produktiv

justme1968

genau so einen offset habe ich ja eingebaut. er wird zufällig beim start bestimmt. kannst du mal bitte verbose auf hoch setzen dann solltest du die jeweiligen offsets und abfragen sehen.

die einzige stelle an der dieser zufällige offset ncht greift ist bei einem reloadconfig. also z.b. auch wenn man das config file in fhem editiert.

beim neustart sollte er immer vorhanden sein.

siehst du die gleichzeitigen abfragen auch nach einem kompletten neustart?

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

ritchie

#6
Hi,

Zitat
genau so einen offset habe ich ja eingebaut. er wird zufällig beim start bestimmt. kannst du mal bitte verbose auf hoch setzen dann solltest du die jeweiligen offsets und abfragen sehen.
nach welchem Eintrag in der LogDatei soll ich suchen ?

Neustart kann ich Dir später sagen, dafür muss ich vor Ort sein.


Edit:


Zitat
Use of uninitialized value in concatenation (.) or string at FHEM/Blocking.pm line 112.
2014.05.02 17:48:59 1: CallBlockingFn: Can't connect to localhost:

Can't use an undefined value as a symbol reference at FHEM/Blocking.pm line 129.
2014.05.02 17:49:22 0: Server shutdown
2014.05.02 17:49:28 1: Including fhem.cfg
2014.05.02 17:49:34 1: Including ./log/fhem.save
2014.05.02 17:50:10 0: Server started with 162 defined entities (version $Id: fhem.pl 5715 2014-05-01 15:02:06Z rudolfkoenig $, o

Ist das normal ? Ist neu.

Ach ja,
ich vergass nochmals zu erwähnen, das ich ja 4 x 1-wire Bus Master habe und die Abfrage dieser derzeit syncron ist. Drei kann ich per LED sehen, der 4 te ist ein RI Onboard 1wire von Busware.

Gruss R.
IPU662  Ipfire & Fhem (Homematic + MAX) - Produktiv
Cubietruck (1Wire - USB) - Produktiv

justme1968

wenn du verbose auf 5 stellst solltest du für jedes OWDevice einen einrag 'initial delay: xxx' sehen.

die meldung ist normal beim runterfahren wenn eines der per nonblocking gestarteten prozesse noch versucht eine meldung an den parent zu senden der schon beendet ist. das ist unkritisch.

der zufällige delay ist völlig unabhängig von der anzahl der busmaster weil er nicht auf OWServer sondern auf OWDevice ebene ist.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

ritchie

Hallo Andre,

das ganze sieht eigentlich ganz gut aus.

Jedoch kann natürlich bei einer kleinen Scanrate, wie ca. 5 oder 10 Sekunden, die reine Abfrage, trotz unterschiedlichem Delay
wieder zum gleichen Zeitpunkt ausgeführt werden.


So werden z.b. diese Abtastungen immer zum gleichen Zeitpunkt (jede nach Abtastrate) durchgeführt. Die Angabe rechts ist jeweils meine Abtastrate.
Zitat
2014.05.02 17:44:27 5: klSteuerungAusgangskarte: initial delay: 0      10 Sek,
2014.05.02 17:44:28 5: klTemperatur1: initial delay: 0               120 Sek.
2014.05.02 17:44:04 5: flDualInput1: initial delay: 0               5 Sek.
2014.05.02 17:44:17 5: klHeizungAbgasTemperatur: initial delay: 0      120 Sek.
...
2014.05.02 17:44:24 5: klNASSteuerung: initial delay: 5               10 Sek.
2014.05.02 17:44:15 5: klDualInput8: initial delay: 5               5 Sek.
2014.05.02 17:44:29 5: klTemperatur3: initial delay: 5               120 Sek.

Ursache liegt evtl. daran, das der Delay ein "kleinste gemeinsame Vielfache" der Abtastrate ist und somit der Delay nicht mehr aktiv  im laufenden Betrieb wird ( Hierdurch ist bei einer Abtastrate von mehrmals 5 Sekunden ein Delay von 10,15,25 letztendlich unwirksam.)

Bei Temperaturen mit einer Abtastrate von 120 Sekunden kommt das jedoch voll zur Wirkung, da hier meist 12...13,, 14 steht.

Wie wäre es mit:
Wenn Du also prüfen würdest, ob der Delay sich sauber durch die Abtastrate teilen läßt, müsstest Du einen neuen Delay ermitteln, oder diesen Wert einfach (mal plus 1 addieren und das nächste Mal minus 1).

Gruss R.








IPU662  Ipfire & Fhem (Homematic + MAX) - Produktiv
Cubietruck (1Wire - USB) - Produktiv

Prof. Dr. Peter Henning

Der richtige Weg, solche Kollisionen zu vermeiden, bestünde in der Einführung eines regulären Ausdrucks für die Abfragezeit - ähnlich, wie das beim cron-Editor gemacht wird.

LG

pah

P.S.: Kleine Korrektur: Eine Abtastrate ist keine Zeitangabe, sondern hat die Einheit 1/Zeit

justme1968

da kommen glaube ich unterschiedliche effekte zusammen die bei dir probleme machen. vor allem das dein intervall in der gleichen größenordnung wie die verzögerung liegt und nur eine auflösung im sekunden bereich möglich ist.

bei 5 sekunden intervall gibt es schon mal nur 4 mögliche verzögerungen die überhaupt etwas bewirken würden. bei mehr als 2 oder 3 sensoren mit 5 sekunden intervall sind kollisionen vorprogrammiert.

das das gilt im prinzip dann auch für die sensoren mit einem ganzzahligem vielfachen intervall.

die zufällige start verzögerung ist nur wirklich hilfreich wenn das intervall groß gegenüber der verzögerung ist.

die 'richtige' lösung für kleine Intervalle ist glaube ich eher das intervall selber zufällig in der länge zu variieren. das wollte ich eigentlich urspünglich einbauen aber ich war mir nicht sicher wie gut das ankommt.

und auch hier würde die geringe auflösung von nur einer sekunde stören.

vielleicht kann man das ganze noch verbessern wenn man zwischen den großen und kleinen Intervallen unterscheidet und darauf achtet das es ungeradzahlige verzögerungen und keine teiler sind.

das ganze von hand konfigurierbar zu machen würde es zwar eventuell vereinfachen aber nicht unbedingt routinetauglich weil man dann auch von hand wieder anpassen muss wenn ein sensor dazu kommt.

eigentlich ist das ganze spielen mit der verzögerung ja auch nur ein workaround bis der asynchrone zugriff geht. da gibt es diese probleme alle nicht mehr. und gerade für kurze abfrageintervalle eigentlich sowieso zwingend nötig.

grad hab ich noch eine idee: wenn man die vertögerungen zwar zufällig aber 'ohne zurücklegen' wählt und dann noch die ganzzahligem vielfachen meidet könnte das auch ein deutliche verbessrung sein.

ich schau mal ob sich das ohne all zu großen aufwand umsetzen lässt.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

ritchie

Hallo Andre,

hier ist nicht wirklich eine Optimierung mit grossem Aufwand notwendig.

Ich versuch heute einfach mal die eine Hälfte der Sensoren die Abtastrate von 5 auf 4 und von 10 auf 9 zu setzen.

Das sollte eigentlich auch schon was bringen.

Gruss R.
IPU662  Ipfire & Fhem (Homematic + MAX) - Produktiv
Cubietruck (1Wire - USB) - Produktiv