Performanceprobleme

[Marha]

Nein, er läuft nicht nach.
Der Überlauf kommt dadurch Zustande, dass die Differenz aus StoppZeit-Restzeit kleiner ist als die PerformanceZeit. Mich wundert nur, dass der Überlauf ein u32 Wert ist, obwohl die Variablen alle u64 sind. Und Rückgabewert von max() sollte doch dann auch u64 sein.
Ich habe nun einiges aus dem Code rausgeschmissen und bin bei einer Auslastung von 20,1 % angelangt. Bei einer Zykluszeit von 50ms erhalte ich nun für MaxZyklusZeit einen Wert von 105 (was 105 ms entspricht) und für MinZyklusZeit einen Wert von 16 (was 16 ms entspricht).
Wenn ich nun die Zykluszeit halbiere also 25 ms dann erhalte ich Werte für MaxZyklusZeit von 368 und für MinZyklusZeit von 7 bei unverändertem Programm. Wie kann ich mir da einen Reim draus machen?

Gruß
Markus

[enertegus]

Ist es sinnvoll mit 50ms zu starten?

Schaden wird das wohl nicht...

Den Wert von MaxZyklusZeit liegt öfter mal im weiter oben erwähnten Bereich, auch wenn ich ihn im EibStudio wieder lösche. Der Wert sieht mir nach einem u32-Überlauf aus, was eigentlich nicht sein kann. Oder habe ich etwas übersehen?

Nun, es könnte sein, dass die Verarbeitung sehr kurz ist, und u32 durch die Differenzbildung einen Überlauf bekommt.
Aber das klingt auch sehr merkwürdig, fast so, als wäre da was mit der Systemzeit nicht in Ordnung. Kannst Du mal die NTP Synchronisierung deaktivieren (EibStudio/NTP Synchronisation), und schauen, ob der EibPC dann zeitlich signifikant hinterherläuft?

[Marha]

Guten Morgen,

leider habe ich noch nichts ausfindig machen können, was die Ursache für den Performance-Einbruch sein kann. Ich verwende häufiger die mpchart Funktion. Kann das zu einer starken Auslastung des Programms führen?
Ich habe nun die Zykluszeit auf 50ms gestellt und bin dabei einzelne Programmteile auszukommentieren, um den Übeltäter ausfindig zu machen. Ist es sinnvoll mit 50ms zu starten?
Den Wert von MaxZyklusZeit liegt öfter mal im weiter oben erwähnten Bereich, auch wenn ich ihn im EibStudio wieder lösche. Der Wert sieht mir nach einem u32-Überlauf aus, was eigentlich nicht sein kann. Oder habe ich etwas übersehen?

Gruß
Markus

[Marha]

Ja, es liegt etwas im Argen in meinem Programm und die Ursache möchte ich finden.
Eine eventuelle Telegrammwiederholung durch einen Aktor habe ich mit der ETS überprüft. Gesehen habe ich nichts auffälliges.
Ausschließen kann ich, dass der hohe Wert beim Programmstart erzeugt wird. Ich setzte den Zähler im EibStudio regelmäßig zurück und nach einer Zeit von ca 10 Minuten ist der hohe Zählerstand wieder erreicht.
Werde jetzt mal auf den Bus eine Nachricht senden, wenn der Zählerstand wieder aus dem Ruder gelaufen ist.
Danke für Deine Tips.
Hat vielleicht sonst noch jemand einen Tip oder ein ähnliches Phänomen?

Gruß
Markus

[enertegus]

Hallo,
ich habe weiterhin massive Probleme mit der Durchlaufzeit bzw der Performance des EibPC. Ich habe nun das neue Patch 2.306.ptc eingespielt.
Ich habe eine Speicherauslastung von 41,7 % und eine Durchlaufzeit von 35ms eingestellt. Folgende Lastwerte kann lese ich mit dem EibStudio v.2.311 aus: 3.46, 3.00, 2.83. Bisher habe ich es noch nicht hinbekommen, dass ich unter 1.00 komme, wie Michael beschrieben hat. Ich habe die Programmzeilen aus dem PDF eingebunden, die die Zyklusdauer des EibPC berechnen. Dabei komme ich auf eine Zyklusdauer von ca MaxZyklusZeit = 950 bei einer Durchlaufzeit von PerformanceZeit=35u64.

Das wäre sehr hoch und es scheint da was im Argen zu liegen. Aber natürlich sind 42% auch nicht so wenig, dass man drauf schaut und sieht, was passiert.
Um die Sache zu finden:
1. Sicherstellen, dass der Maxwert nicht beim Initialisieren auftritt, dass kann schon mal einige Sekunden dauern
2. Am besten, dann wenn max. Zeitdauer eintrifft, eine Meldung auf den Bus schreiben. Dann kann man ggf. im Programm sehen, was zu diesem Zeitpuntk so los war.
3. Events: Ggf. hat der Bus/Schnitttstelle ein Problem. Ich hatte mal einen Aktor unvollständig programmiert und dann gab es soviele Telegrammwiederholungen, dass alles zu spät war.
4. 3.46, 3.00, 2.83 zeigt die durchschnittlich aktiven Threads an. Ein FTP Transfer z.B: dauert ja einige Zeit und dann wird dieser Threadzähler um 1 erhöht. Es bedeutet nicht notwendigerweise das Schlimmste.

[Marha]

Hallo,

ich habe weiterhin massive Probleme mit der Durchlaufzeit bzw der Performance des EibPC. Ich habe nun das neue Patch 2.306.ptc eingespielt.
Ich habe eine Speicherauslastung von 41,7 % und eine Durchlaufzeit von 35ms eingestellt. Folgende Lastwerte kann lese ich mit dem EibStudio v.2.311 aus: 3.46, 3.00, 2.83. Bisher habe ich es noch nicht hinbekommen, dass ich unter 1.00 komme, wie Michael beschrieben hat. Ich habe die Programmzeilen aus dem PDF eingebunden, die die Zyklusdauer des EibPC berechnen. Dabei komme ich auf eine Zyklusdauer von ca MaxZyklusZeit = 950 bei einer Durchlaufzeit von PerformanceZeit=35u64.
Manchmal beträgt die MaxZyklusZeit = 4294967270.
Was bedeutet dies?
Nach welchen Konstrukten muss ich in meinem Programm ausschau halten, die die Performance so in die Knie gehen lässt?
Benötigt eine TCP-Verbindung oder sendmail eine solch hohe Last?
Ich wüsst nicht, dass es eine "gewollte" Stelle im Programm gibt, die dafür sorgt, dass das halbe Programm validiert wird. Ich verwende kein VPN oder FTP. Lediglich TCP, UDP und sendmail.
Ich hoffe, ihr könnt mir da weiterhelfen.

Gruss
Markus

[Marha]

Mir ist jetzt im Moment nicht bewusst, welche Variable bei mir den gesamten Code invalidieren würde. Aber ich werde mal den Code danach untersuchen.
Danke für den Hinweis

Gruß
Markus

[enertegus]

Die Frage wäre jetzt für mich was diese 12 cycle(0,1) machen, das es diesen extremen Einbruch an Performance bringt.

Habe eben folgendes getestet:
Makro:

:begin SekTimer(Name)
Var1_Name = 0b01
Var2_Name = 0b01
Var3_Name = 10u08
counter_Name = 0u08
if cycle(0,1) and Var1_Name and !Var2_Name then {
    if counter_Name < Var3_Name then counter_Name = counter_Name + 1u08 endif
    } endif
:end

Damit dann
[Highlight=epc]
[Macros]
SekTimer(T1)
SekTimer(T2)
SekTimer(T3)
SekTimer(T4)
SekTimer(T5)
SekTimer(T6)
SekTimer(T7)
SekTimer(T8)
SekTimer(T9)
SekTimer(T10)
SekTimer(T11)
SekTimer(T12)
SekTimer(T13)
SekTimer(T14)
SekTimer(T15)
SekTimer(T16)
SekTimer(T17)
SekTimer(T18)
SekTimer(T19)
SekTimer(T20)
SekTimer(T21)
SekTimer(T22)
SekTimer(T23)
SekTimer(T24)
SekTimer(T25)
SekTimer(T26)
SekTimer(T27)
SekTimer(T28)
SekTimer(T29)

[MacroLibs]
//Makro-Bibliotheken
/Users/michi/Haus/mymacro.lib


[ETS-ESF]
// Die aus der ETS3 exportierte ESF-Datei
/Users/michi/Haus/Haus.esf

[EibPC]
// Berechnet die minimale und maximale Zyklusdauer
// der Verarbeitung. Dabei ist die Performance-Angabe im EibStudio immer
// als Offset dabei.
Max=1000000u64
Zeit=0u64
StoppZeit=Max
MaxZyklusZeit=0u64
MinZyklusZeit=Max
// Die erste Zyklus kann etwas länger dauern, da
// dieser alles initialisiert.
if afterc(after(systemstart(),10000u64), Max, Zeit) then {
StoppZeit=0u64;
} endif

if change(Zeit) then {
MaxZyklusZeit=max(StoppZeit-Zeit,MaxZyklusZeit);
MinZyklusZeit=min(StoppZeit-Zeit,MinZyklusZeit);
StoppZeit=Zeit;
} endif

[/Highlight]
Wenn ich nun mit den 29 Timern debugge und MaxZykluszeit anschau, komme ich auf eine max. Zykluszeit von 24ms (eingestellt sind 20ms). Demnach ist die Verarbeitungszeit maximal 4 ms und damit Faktor 1000 kleiner als die genannte.
Ich vermute, dass Problem liegt im Code woanders oder nur indirekt bedingt von dem cycle z.B. von einer Variable ist nahezu alles abhängig. Sowas führt dazu, dass, wenn sich diese ändert, der gesamte Code invalidiert würde.

[bmx]

Die Frage wäre jetzt für mich was diese 12 cycle(0,1) machen, das es diesen extremen Einbruch an Performance bringt.

Vielleicht kann uns enertex diesbezüglich mal erhellen? Dann könnte man sich gezielt auf die Jagd nach solchen Performancefressern begeben...

Gruß,
Bernd

[Marha]

Habe die Stellen gefunden. Es sind 12 Abfragen in folgender Art hinzugekommen, die mir wohl die Performance geklaut haben.

Var1 = 0b01
Var2 = 0b01
Var3 = 10u08
counter = 0u08
if cycle(0,1) and Var1 and !Var2 then {
    if counter < Var3 then counter = counter + 1u08 endif
    } endif

Das sollte eigentlich bewirken, dass jede Sekunde ein Zähler inkrementiert wird, um eine Zeit von 10 sec zu "messen".

Ohne diese Abfragen liegt die load average jetzt wieder im normalen Bereich (load average: 0.77, 0.67, 1.08) und die Reaktion des eibPC ist wieder in Ordnung.

Gruß
Markus

[Jambala]

Ich würde Deinen Code einmal in Abschnitte aufteilen und dann erst einmal mit einem Hauptabschnitt starten und die Last beobachten. Dann step by step einen zusätzlichen Abschnitt hinzufügen, neustarten und Last anschauen.

Irgendwann sollte dann klar sein welcher Code Abschnitt dafür verantwortlich ist.

[Marha]

Benutze folgende Libs:
Enertex.lib
EnertexBeschattung.lib
EnertexLicht.lib
EnertexWebV2.lib
CHGLibrary_FritzBox.lib
die Wetterdaten werden von Wunderground geholt

und dann noch einige selbst geschriebene. Aber die wurden vorher auch schon alle verwendet. Es ist keine neue Lib hinzugekommen.
Verwende kein ftp und keinen Lese-/Schreibzugriff auf den flash.

Unter den Wert 2 komme ich ganz sicher nicht.
Wie kann ich mich dem Problem am Besten nähern?

Gruß
Markus

[Marha]

Ein Neustart war ohne nennenswerten Erfolg

[enertegus]

09:29:15 up 69 days, 20:12, 0 users, load average: 7.03, 4.23, 3.44

ein Neustart bringt da nix. Die Auslastungsanzeige ist direkt vom Linuxkernel, Erklärung Load.
Dass die beim Systemstart höher liegt, ist schon ok, wobei sie hin und wieder schon mal unter 1 sinken sollte. Es kommt aber auch darauf an, was man macht. So erhöht die ftp-Auslagerung die Threadbelastung, also wird der Wert 1 hinzukommen, aber der Prozess hat geringe Priorität und daher den EibPC nicht belasten, genauso wie email.
Bei mir ist die Auslastung im Speicher 45%, die Systemload ist 0,8 bis 2,0. Alleine die 100 cwtimer werden das Problem nicht darstellen. Was genau machst du alles, bzw. welche Libs bindest Du ein?

[Marha]

Habe nun mal die Durchlaufzeit auf 50 ms gesetzt. Folgendes Ergebnis:
Patches:
2.304.ptc
Boot image:
Boot image fixes: 0
Boot image updates: 10
Uptime:
09:29:15 up 69 days, 20:12, 0 users, load average: 7.03, 4.23, 3.44
VPN-Status:
The openvpn daemon is not running.
Konfigurierte VPN-Benutzer:

Werde den eibPC jetzt mal neu booten.

Gruß
Markus