ms nicht gleich ms

[amazing]

habe mal das Script bzgl. Auslastung eingebaut.
s. Bilder im Anhang.
Muss ich mir Sorgen machen wegen den Peaks über 800ms, oder ist das noch normal?
Des Weiteren ist das 'Grundrauschen' mal stärker mal nur sehr gering.

CPU Auslastung war bei 32%, Freier Speicher ca. 12400kb
Habe 6 timebuffer, nach Übertragung mit Transferdialog, habe die zusammen ca. 2,4 MB. Wo geht der ganze Speicher verloren?

Gruß
Ralf

[saft6luck]

Schaut nicht so gut aus.

Problematisch ist die Überlast, weil der eibPC in der Zeit offenbar auch die Grafik nicht updatet. Das sieht man an der Steigung der Peaks -> sie sind zu flach. Sie dauern mehrere Sekunden, in denen der eibPC nur einen Wert in das Chart schreibt. Teilweise fehlen auch Werte danach.

Wenn du tatsächlich jede Minute eine derartige Überlast hast und der Code dann für ein paar Sekunden steht, würde ich hier die Ursache sehen.

Laut deiner Angaben hat der eibPC in 74 Minuten eine Abweichung von 268.000 ms, was dann (zufällig) exakt 3 Sekunden pro Minute sind.

Welches Makro läuft denn jede Minute? Evtl. kannst du das ja mal rausnehmen und dann die Zeiten der Bewässerung noch einmal prüfen?

[amazing]

ok, werde mich morgen nachmittag mal auf die Suche machen
Ungeachtet dessen, hätte ich so ein Risiko , dass der eibPC instabil ist? Oder wäre im worst case nur das ms ungleich ms Problem?

Gruß

Ralf

[amazing]

Also ich würde ja eher dazu raten das ganze über die Treppenhausfunktion des Aktors zu lösen, denn wenn aus irgend einem Grund der EibPC während der aktiven Bewässerung nicht mehr reagiert oder du zufällig das Programm neu überträgst, dann wird es richtig schon nass auf dem Rasen. Bei den meisten Aktoren kannst du die Zeit für die Treppenhausfunktion über eine Gruppenadresse übergeben. Damit ist gewährleistet, dass der Aktor nach einer bestimmten Zeit sicher wieder auf AUS geht. Falls das nicht geht, dann die Treppenhausfunktion einfach jede Minute neu antriggern.

habe ich, der Aktor der die Hauptwasserleitung schliesst ist mit Treppenlichtfunktion parametriert. Wenn eibPC also ausfällt, dann schliesst Ventil auf jeden Fall nach Treppenlichtzeit

[amazing]

Schaut nicht so gut aus.

Problematisch ist die Überlast, weil der eibPC in der Zeit offenbar auch die Grafik nicht updatet. Das sieht man an der Steigung der Peaks -> sie sind zu flach. Sie dauern mehrere Sekunden, in denen der eibPC nur einen Wert in das Chart schreibt. Teilweise fehlen auch Werte danach.

Wenn du tatsächlich jede Minute eine derartige Überlast hast und der Code dann für ein paar Sekunden steht, würde ich hier die Ursache sehen.

Laut deiner Angaben hat der eibPC in 74 Minuten eine Abweichung von 268.000 ms, was dann (zufällig) exakt 3 Sekunden pro Minute sind.

Welches Makro läuft denn jede Minute? Evtl. kannst du das ja mal rausnehmen und dann die Zeiten der Bewässerung noch einmal prüfen?

Also......
an den Makros wie Wetter und an den mtimecharts hat es nicht gelegen.
Mir fiel allerdings auf, dass ich viele stime(0) habe. Da die Peaks immer zur vollen Minuten kamen, könnte hier ja die Ursache sein.
Habe mal stime auf andere Sekunden verteilt. Jetzt zeigt sich die Log Grafik so.

Würde mir einen ebiPC mit mehr Power und RAM sowie SD Karten Erweiterung wünschen :-)

[saft6luck]

Also......
an den Makros wie Wetter und an den mtimecharts hat es nicht gelegen.
Mir fiel allerdings auf, dass ich viele stime(0) habe. Da die Peaks immer zur vollen Minuten kamen, könnte hier ja die Ursache sein.
Habe mal stime auf andere Sekunden verteilt. Jetzt zeigt sich die Log Grafik so.

Die spannende Frage: Hast du schon getestet, ob die Timings dann besser sind?

[amazing]

so konnte heute mal testen, die in Post 1 mehr als 4 min längere Zeit reduzierte sich jetzt auf eine nur 15 sec längere Zeit. Das ist ja eindeutig.

Wäre mal von enertex zu testen ab wieviel stime(0) Einträge der eibPC in die Knie geht.

[Marha]

Das Problem mit zu vielen Timern hatte ich in meinem Programm auch schonmal. Abhilfe war, das ganze Programm nach Timern zu durchsuchen und radikal timer reduzieren. Hat bei mir eine wesentlich bessere Performance gebracht.
Wie sind Deine nice-werte?

[enertegus]

Das Problem mit zu vielen Timern hatte ich in meinem Programm auch schonmal.

Ich kann mich erinnern: Es waren über 3000 (!) after-Timer. Das kann insbesondere dann passieren, wenn diese in Makros sehr intensiv genutzt werden und die Makros quasi Bestandteil jeder Codezeile werden.
Ich habe mir eben auch das Wundergroundmakro angesehen. Ich denke, hier gibt es einiges zum Umschreiben. Es sind ca. 300 Stringvergleiche über ca. 3kByte. Das kann schnell mal in die hundert-ms Zeitverbrauch gehen, weil jeder Stringvergleich von vorne anfangen muss.

[Marha]

Ah, das ist ein guter Hinweis.
Habe mich an dieses Makro angelehnt und einige Steingvetgleich in ähnlicher Weise durchgeführt. Das wäre dann auf meiner Seite auch noch zu andern.
Bin auf das neue Makro gespannt.

Übrigens, es waren ca. 800 Timer.

Gruß Markus

[enertegus]

Übrigens, es waren ca. 800 Timer.

Du musst auch jeden after und htime mitzählen.

[Marha]

Ja, delay ect. War auch dabei. Wollen uns ja auch nicht um die Paar Timer streiten. Jedenfalls waren es zu viele. Das ist sicher!

Gruß Markus