Ankündigung

Einklappen
Keine Ankündigung bisher.

EibPC - Problem mit chtime - ggf. Performance-Thema?

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    EibPC - Problem mit chtime - ggf. Performance-Thema?

    Hallo,

    den EibPC nutze ich seit 2011 und bin auch eigentlich sehr zufrieden. Mit zunehmender Programmlänge stoße ich nun auf komische Verhaltensweisen, die ich mir nicht recht erklrären kann.
    Ich steuere bspw. meine Raumthermostate nach Anwesenheit, Wochentag und Zeit. Die folgende Abfrage funktioniert leider nicht zuverlässig, weder morgens um 6 Uhr (wenn wir üblicherweise da sind ;-)) noch wenn wir wieder nach Hause kommen (bei Setzen der Variable AnwesendAllgemeinFlag passiert recht viel an Logik-Auswertungen...):

    Code:
    if AnwesendAllgemeinFlag == EIN \\
        and (Wochentag == 1 or Wochentag == 2 or Wochentag == 3 or Wochentag == 4 or Wochentag == 5) \\
        and chtime(06,00,00) \\
        and !chtime(19,59,00) then {
            tempHeizungsmodus = 1s08;
            write("VirtGesamt Text-0/2/50",$HZM 5$c14);
        } endif
    Zur Erläuterung:
    - in der Variable "Wochentag" wird täglich der Wochentag abgelegt, das war schon ein verzweifelter Versuch, ob es damit zusammenhängt
    - tempHeizungsmodus wird zum Umsetzen der Heizungsbetriebsart genutzt
    - VirtGesamt Text-0/2/50 ist fürs debuggen gedacht


    Deutlich besser - soweit ich beurteilen kann zuverlässig - klappt es hiermit, auch wenn ich mir das logisch nicht erklären kann:
    Code:
    if AnwesendAllgemeinFlag == EIN \\
        and (Wochentag == 1 or Wochentag == 2 or Wochentag == 3 or Wochentag == 4 or Wochentag == 5) \\
        and AktuelleZeitInSekundenZehner >= 21600s32 \\
        and AktuelleZeitInSekundenZehner < 72000s32 then {
            tempHeizungsmodus = 1s08;
            write("VirtGesamt Text-0/2/50",$HZM 5$c14);
        } endif
    Wie man sieht, ist nur chtime durch eine im 10-Sekunden-Takt aktualisierte Variable ersetzt worden.

    Was mir bei meinen Analysen aufgefallen ist - und das ist jetzt mein Verdacht hinsichtlich der Performance - dass mein EibPC ganz schön beschäftigt ist:
    Code:
    IP-Adresse des EibPCs: 192.168.4.40
    Firmwareversion des EibPCs: v3.030
    Seriennummer des EibPCs: 00000406
    Netzwerkeinstellungen: Statisch
        Netzmaske:    255.255.255.0
        Gateway:      192.168.4.100
        Nameserver 1: 192.168.4.100
        Nameserver 2: ?
        Nameserver 3: ?
    Physikalische Adresse: 00-50-c2-79-31-5f
    Patches:
    3.027.ptc
    Boot image:
    Boot image fixes: 0
    Boot image updates: 3
    System boot time: Wed Feb 10 22:01:10 CET 2016
    Average CPU usage since booting: 69 %
    Maximum available firmware memory: 21720 kb
    Telegram buffer reduced to: 150000
    VPN: The openvpn daemon is not running.
    Allowed VPN users:
    EIB-Schnittstelle: EIBnet/IP (Verbindung aufgebaut)
    (P.S.: Auch vor dem letzten Update war das Problem da, der letzte Patch hatte keine Besserung gebracht)

    Ich hatte auch schon mal die Zykluszeiten mir laufend mitgezählt (in Kategorien von bis), die schwankt zwischen 100 ms und in Spitze auch mal über 900 ms, leider kommen die über 900 ms ein paar mal am Tag vor.... In einem anderen Thread war mal die Rede davon, dass in der Spitze die Zykluszeit in Richtung 1 Sekunde schon kritisch ist (dauernd die Zykluszeiten messen und in eine Variable packen kostete auch nochmal 5-10 Prozentpunkte Average CPU usage, das habe ich dann wieder herausgenommen). Auch scheint die Nutzung der Visu den EibPC je nach Anzahl der Elementen ganz schon zu beschäftigen, daher habe ich die neuartigen Charts auch gleich wieder herausgenommen...

    Frage 1: Hat jemand Ideen zum chtime-Problem?

    An sich würde ich meinen, dass die durchschnittliche CPU-Auslastung deutlich zu hoch ist, aber eine Idee, was ich dagegen ohne Feature-Verlust wirklich tun kann, habe ich nicht, schließlich möchte ich die Logiken ja im EibPC programmieren und nicht anderswo, dafür habe ich ihn ja. Aber ich sehe mich schon fast gezwungen, manche Dinge jetzt auf meinen BananaPi auszulagern, damit der EibPC sich nicht so anstrengen muss... ;-).

    Frage 2: Über Hinweise, welche Befehle / Programmlogiken den EibPC viel beschäftigen, bin ich dankbar.


    #2
    Zitat von georg123 Beitrag anzeigen
    Wie man sieht, ist nur chtime durch eine im 10-Sekunden-Takt aktualisierte Variable ersetzt worden.
    Das kann ich mir eigentlich überhaupt nicht erklären. Gerade chtime ist ja über mehrere Strunden auf EIN. Selbst wenn Du Zykluszeiten über die kritische Sekunde hast, funktioniert chtime sicher noch.
    verage CPU usage since booting: 69 %
    Ja, das ist schon sehr, sehr viel.
    Auch scheint die Nutzung der Visu den EibPC je nach Anzahl der Elementen ganz schon zu beschäftigen, daher habe ich die neuartigen Charts auch gleich wieder herausgenommen...
    Nun ja, da wurde einiges verbessert. Aber wenn man nicht gerade 200 x 65000 lange Aufzeichnungen anstößt (was auch phy. nicht geht), sollte das nicht so drastisch sein.
    sich würde ich meinen, dass die durchschnittliche CPU-Auslastung deutlich zu hoch ist, aber eine Idee, was ich dagegen ohne Feature-Verlust wirklich tun kann, habe ich nicht, schließlich möchte ich die Logiken ja im EibPC programmieren und nicht anderswo, dafür habe ich ihn ja.
    Nun, was sagt denn dein Compileroutput?
    Frage 2: Über Hinweise, welche Befehle / Programmlogiken den EibPC viel beschäftigen, bin ich dankbar.
    Na da müssten wir wissen, was genau Du alles machst. Oft sind es irgendwelche Debug-Meldungen (vgl. https://knx-user-forum.de/forum/suppo...rmalen-betrieb). Hmm...
    offizielles Supportforum für den Enertex® EibPC: https://knx-user-forum.de/eibpc/
    Enertex Produkte kaufen

    Kommentar


      #3
      Moin Frank,

      wenn von einer einzige Variable sehr viel abhängt, muß natürlich etliches neu berechnet werden. Das kann schon mal dauern oder im Extremfall "zu lange dauern". Eine gute Idee ist es dann das alles zu entzerren. Sicher kannst Du das eine oder andere dann zeitlich ein paar Sekündchen verzögern, z.B. mit if after( AnwesendAllgemeinFlag, ... 2000u64) oder ähnlichen Konstrukten wie if change( AnwesendAllgemeinFlag).

      Gruß,
      Bernd

      Kommentar


        #4
        Vielen Dank für Eure Rückmeldungen, fangen wir mal hinten an:

        @Bernd: An die Verzögerung habe ich auch schon gedacht, aber damit das wirklich was bringt, müßte ich doch eine "if after( AnwesendAllgemeinFlag, ... 2000u64) then AnwesendAllgemeinFlagZwei = AnwesendAllgemeinFlag" -Konstruktion aufmachen und dann auf die Veränderung von AnwesendAllgemeinFlagZwei abzielen. Ich hätte Sorge, wenn ich jeweils noch einen Timer anwerfe, dass es dann in dem Moment der Wiederkehr (AnwesendAllgemeinFlag = EIN) noch mehr Probleme gibt. Die "change()"-Anweisung würde doch auch nur in dem Durchlauf der Anwesenheitswiederkehr ausgewertet, genau in dem Takt ist doch gerade die große Zykluszeit gegeben, oder übersehe ich da was?

        @energetus:
        Ich kann es mir mit chtime ja auch nicht erklären, aber ich habe es wochenlang beobachtet, morgens um 6 Uhr klappte es einfach nicht, bei Rückkehr wenn AnwesendAllgemeinFlag = EIN gesetzt wird, dagegen sehr oft... bei anderen chtime-Anweisungen habe ich nie Probleme bemerkt (nutze ich auch für viele andere Sachen). Ich habe mir eingebildet, dass es erst durch die Hinzunahme der Wochentag-Bedingung problematisch wurde.

        Mit dem Compileroutput ist wohl das hier gemeint:
        Code:
        Keine Haftung für Schäden, die durch die Benutzung des Programms entstehen.
         Gruppenadressen-Import:
         Datei: "D:/KNX/Enertex/EIBStudio_3/EibstudioData/tmpAddr.txt" wurde geschrieben
         Datei: "D:/KNX/Enertex/EIBStudio_3/EibstudioData/tmpMacroOut.txt" wurde geschrieben
        
         Datei: "D:/KNX/Enertex/EIBStudio_3/EibstudioData/tmpMacroFuncOut.txt" wurde geschrieben Gruppenadressen - Konvertierung Datentypen:
         Datei: "D:/KNX/Enertex/EIBStudio_3/EibstudioData/tmpAddr.txt" wurde geschrieben
         Datei: "D:/KNX/Enertex/EIBStudio_3/EibstudioData/tmpDebug.txt" wurde geschrieben
         Datei: "D:/KNX/Enertex/EIBStudio_3/EibstudioData/tmpObjects.txt" wurde geschrieben
         Datei: "D:/KNX/Enertex/EIBStudio_3/EibstudioData/tmpAssign.txt" wurde geschrieben
         Datei: "D:/KNX/Enertex/EIBStudio_3/EibstudioData/tmpConf.txt" wurde geschrieben
        
         Setze UDP Eingangsport auf:     4806
         Setze UDP Ausgangssport auf:    4807
         Setze TCP Port auf:             4809
         Setze ModBusTCP Port auf:       502
         --------------------------------------      --------------------------------------
         Objektnutzung                 | Anzahl      Webserverobjekte              | Anzahl
         ======================================      ======================================
         Schaltuhr                     |    280      button                        |      1
         Timer                         |    111      mpchart                       |     25
         Timebuffer                    |      0      pbutton                       |     61
         String Operationen            |    454      pshifter                      |     10
         TCP/IP/UDP Operationen        |     13      shifter                       |      1
         Stringsuche                   |      4      --------------------------------------
         Flash                         |      0               Summe (25 Webseiten) |     98
         Fliesskommaoperationen        |     13
         if/else                       |   1179
         Gruppenaddressen              |    591
         KNX Busoperationen            |   1679
         Stringvariablen               |     71
         Verarbeitungsobjekte          |   7595
         --------------------------------------
                                 Summe |  11990
        
         Genutzte Objekte EibPC  18.3 %.
         Funktionen der Option NP verwendet
        
         EibParser wurde ohne Fehler beendet.
        Dazu noch ein paar Erläuterungen:
        Ich habe zwar viele Webseiten, auf etlichen ist jedoch kaum etwas drauf, ich wollte das eigentlich ausbauen, hänge nun aber am Perfomance-Problem. Da ich eigentlich immer nur auf die "Genutzte Objekte-Prozentzahl" geguckt habe, fühlte ich mich da ganz wohl... bis jetzt halt.
        Aufzeichnungen (abgesehen von der Standard-Telegramm-Protokollierung) nutze ich sonst gar nicht, alle Telegramme bekommt mein BananaPi per UDP, der schreibt die in eine Datenbank. Telegramme auf dem Bus habe ich so um 22.000 am Tag (ist nicht wenig, ich weiß, aber ich bin ein Kontrollfreak ;-)).
        Größere Debug-Geschichten nutze ich derzeit nicht, ein paar Ausgaben auf der "VirtGesamt Text-0/2/50", aber nicht übermäßig viel.

        Ich liste auch gerne auf, was ich so an Logiken verbaut habe oder lege meine Quellcode komplett offen, wenn sich hier damit jemand beschäftigen möchte, aber vielleicht reicht das oben für die ersten Hinweise...

        Danke nochmals für die Hilfe und Gruß
        Frank
        Zuletzt geändert von georg123; 21.02.2016, 01:00.

        Kommentar


          #5
          Nachdem energetus schrieb, dass die 69% schon recht viel sind, habe ich nochmal etwas herumexperimentiert, dabei habe ich auch mal die Visu rausgeschmissen, das bringt dann schon fast 30 Prozentpunkte...

          Code:
          IP-Adresse des EibPCs: 192.168.4.40
          Firmwareversion des EibPCs: v3.030
          Seriennummer des EibPCs: 00000406
          Netzwerkeinstellungen: Statisch
              Netzmaske:    255.255.255.0
              Gateway:      192.168.4.100
              Nameserver 1: 192.168.4.100
              Nameserver 2: ?
              Nameserver 3: ?
          Physikalische Adresse: 00-50-c2-79-31-5f
          Patches:
          3.027.ptc
          Boot image:
          Boot image fixes: 0
          Boot image updates: 3
          System boot time: Sun Feb 21 09:34:37 CET 2016
          Average CPU usage since booting: 41 %
          Maximum available firmware memory: 15296 kb
          VPN: The openvpn daemon is not running.
          Allowed VPN users:
          EIB-Schnittstelle: EIBnet/IP (Verbindung aufgebaut)
          %

          Kommentar


            #6
            Zitat von georg123 Beitrag anzeigen
            "change()"-Anweisung würde doch auch nur in dem Durchlauf der Anwesenheitswiederkehr ausgewertet, genau in dem Takt ist doch gerade die große Zykluszeit gegeben, oder übersehe ich da was?
            ich würde das auch erst mal nicht als Ursache sehen. Wenn ich Deine Programmgröße sehe und die Ausgabe des Compilers, schaut das erst mal nicht so schlecht aus.
            @energetus:
            Ich kann es mir mit chtime ja auch nicht erklären, aber ich habe es wochenlang beobachtet, morgens um 6 Uhr klappte es einfach nicht, bei Rückkehr wenn AnwesendAllgemeinFlag = EIN gesetzt wird, dagegen sehr oft
            Das können wir so leider gar nicht erkennen. Wie ist denn der EibPC an den Bus angebunden, gibt es events? Wenn ja, welche? Wir hatten es auch schon, dass es aufgrund der Probleme von Fritzboxen mit den Mulitcasts der KNXnetIP-Protocolle verrückt gespielt haben und den EibPC zugemüllt hatten.
            Nochmal: Dass chtime nicht läuft, kommt mir mehr als merkwürdig vor.
            Genutzte Objekte EibPC 18.3 %.
            Das schaut gut aus.
            immer nur auf die "Genutzte Objekte-Prozentzahl" geguckt habe, fühlte ich mich da ganz wohl... bis jetzt halt.
            In erster Näherung ist das auch so. Allerdings könnte irgendein Programmteil noch ungünsitg sein.
            Ohne Visu 40%, erscheint mir viel. Ich habe hier mit Visu (27 Seiten), Sequeezebox, Anwesenheitssimulation, Datenlogging, emailversand gerade mal 37%. Die Visu deaktivieren ist da sicher keine Lösung.

            Wir müssen da genauer nachforschen: Wie hast Du denn die Visuelemente eingebunden? Mit unseren Makros oder mit eigenen. Wenn ja , wie schauen die aus?

            Aufzeichnungen (abgesehen von der Standard-Telegramm-Protokollierung) nutze ich sonst gar nicht, alle Telegramme bekommt mein BananaPi per UDP
            Wie schaut der Code hierzu aus? Warum willst Du nicht den EibPC als FTP Logger nutzen (ok, das wäre nur Binär, aber man kann es auch hinterher mit EibStudio decodieren.
            Kannst Du mal dieses Debugging deaktivieren? Es ist zwar UDP lange nicht so aufwendig, wie TCP aber ich denke man muss so ran gehen.
            Ich liste auch gerne auf, was ich so an Logiken verbaut habe oder lege meine Quellcode komplett offen, wenn sich hier damit jemand beschäftigen möchte, aber vielleicht
            Mach doch mal die Liste. Den Quellcode... da schauen wir noch. In 20.000+ Zeilen findet man nicht so leicht eine Antwort...
            offizielles Supportforum für den Enertex® EibPC: https://knx-user-forum.de/eibpc/
            Enertex Produkte kaufen

            Kommentar


              #7
              Hallo,

              ich habe auch so meine Erfahtung mit der Performance des eibPC gemacht. Ich hatte da mal für eine Raumtemperaturregelung ein Makro geschrieben und verwendet. Daraus entstanden in Summe mehrere hundert Timer (htime und auch chtime), für jeden Raum eben und eben für jeden Tag. Das führte auch dazu, dass htime/chtime nicht mehr zuverlässig funktionierte. Ich hatte dazu mal eine Diskussion mit Michael und nach Reduzeriung der Timer funktionierte es auch zuverlässiger. Es ist eben etwas Schwierig, wenn man nicht genau weiß, wie der eibPC letzlich arbeitet, den Code entsprechend zu gestalten. Der Code, den man implemetiert mag formal richtig sein, aber ob er effizient ist, bemerkt man manchmal erst während der Laufzeit. Es gibt in der Doku ein Beispiel, um die Programmdurchlaufzeit zu bestimmen. Dies hat mir z.B. geholfen,um zu bemerken, dass die Programmdurchlaufzeit alle 00:05:00 sec (also 5 min) recht hoch war, warum auch immer. Michael erklärte mir, dass immer dann die Sonnenstandsberechnungen durchgeführt werden, wenn ichs noch richtig in Erinnerung habe. Genau in dieses Raster würde Dein chtime(06:00:00) fallen. Muss chtime genau um 06:00:00 durchgeführt werden? Ich habe alle Timer entsprechend versetzt, was nach meinem Empfinden etwas zur Entspannung der Situation geführt hat. Ein ähnliches Thema war die Verwendung des Wettermakros in der ersten/frühen Version. Die Verarbeitung der Strings führte zu einer erheblichen Prozessorlast, was dann aber in der jetzigen Version des Makros entzerrt wurde.
              Auch sollte man mal mit den Performancezeiten spielen. Wie sind die bei Dir eingestellt?
              Im Moment habe ich selbst einiges an Funktion aus dem eibPC herausgenommen und letzlich nur eine einfache Visu mit Switches in Verwendung. Allein bei dieser Verwendung ist der eibPC schon mit mehr als 26 % ausgelastet, was ich als viel erachte, da eigentlich nur Schaltbefehle gesendet werden und auf Statusmeldungen vom Bus reagiert werden muss/soll. Hauptsächlich verwende ich die Makros aus der aktuellen MakroLib.
              Ich möchte hier keinesfalls den Eindruck erwecken, dass ich den eibPC für ein schlechtes Produkt halte. Im Gegenteil, ich halte den einPC immernoch für sehr gut, ebenfalls ist der Support zu Loben. Mir fehlt in der Doku ein Kapitel Richtung "best practice", was man sich erst selbst erarbeiten oder durch den Support erfragen muss. Für Anregungen/Erfahrungen/Tipps wäre ich dankbar. Leider weiß ich auch nicht so recht, wie man das Thema Performance anstoßen kann.

              Kommentar


                #8
                Hallo,

                danke für die weitere Antworten/Fragen.

                @energetus:
                Das können wir so leider gar nicht erkennen. Wie ist denn der EibPC an den Bus angebunden, gibt es events? Wenn ja, welche? Wir hatten es auch schon, dass es aufgrund der Probleme von Fritzboxen mit den Mulitcasts der KNXnetIP-Protocolle verrückt gespielt haben und den EibPC zugemüllt hatten.
                Ich habe eine Fritzbox 7490, der EibPC kommuniziert über das SIEMENS 5WG1 148-1AB22-IP-Interface (würde ich auch gerne mal gegen eins austauschen, dass mehrere Verbindungen parallel bedienen kann...), der Event-Speicher sieht für mich unkritisch aus (da ich heute Mittag etliche Varianten ausprobiert habe, habe ich nichts älteres...):
                Code:
                % Event: "St Bad OG Alles Licht-1/2/6":ERR_READ_GROUP_ADDRESS@2016-02-21 14:30:01
                % Event: "St Küche Alles Licht-1/1/161":ERR_READ_GROUP_ADDRESS@2016-02-21 14:30:03
                % Event: "St WZ Alles (Licht)-1/1/151":ERR_READ_GROUP_ADDRESS@2016-02-21 14:30:05
                % Event: "St Sperre gegen versehentliches Ausloesen aufheben-0/3/7":ERR_READ_GROUP_ADDRESS@2016-02-21 14:30:15
                % Event: "PseudoGANieZuVerwenden-0/5/1":ERR_READ_GROUP_ADDRESS@2016-02-21 14:30:17
                % Event: closetcp(SatRecPort,SatRecIP):ERR_PROC_OBJECT_MSG_OUT@2016-02-21 14:31:02
                Wir müssen da genauer nachforschen: Wie hast Du denn die Visuelemente eingebunden? Mit unseren Makros oder mit eigenen. Wenn ja , wie schauen die aus?
                Die Visu ist bei mir nur mit den Standard-Makros gebaut (einzig ein InitGA habe ich in der EnertexWebV3.lib zusäztlich eingebaut sowie das UmschaltShifter-Makro auch in einer globalen Variante bereitgestellt), die Dateien dazu habe ich mal angehängt:
                EIBPC_Visu_Frank.zip

                Wie schaut der Code hierzu aus? Warum willst Du nicht den EibPC als FTP Logger nutzen (ok, das wäre nur Binär, aber man kann es auch hinterher mit EibStudio decodieren.
                Kannst Du mal dieses Debugging deaktivieren? Es ist zwar UDP lange nicht so aufwendig, wie TCP aber ich denke man muss so ran gehen.
                Der Code ist recht simpel, ich habe den auch mal für eine halbe Stunde deaktiviert, das hat aber nichts gebracht (vielleicht einen Prozentpunkt). Ich nutze diese Variante, weil ich eben die Binärdateien immer selbst über das EibStudio erst nachbearbeiten muss, auf meinem Weg landen die in einer MySQL-Datenbank und ich kann sofort Abfragen/Auswertungen damit erstellen (wobei ich das noch ausbauen wollte ;-)):

                Code:
                if event(readknx(KNX_GA,KNX_Info)) then {
                    UDPZaehler = UDPZaehler + 1u32;
                    sendudp (11001u16, 192.168.4.30,$DATUM::$+DatumText+$::ZEIT::$+convert(hour(),$$)+$.$+convert(minute(),$$)+$.$+convert(second(),$$)+$::SENDER::$+convert(RawKNX_Sender,$$)+$::GA::$+convert(KNX_GA,$$)+$::LEN::$+convert(RawKNX_Len,$$)+$::INFO::$+convert(KNX_Info,$$)+$::ZAEHLER::$+convert(UDPZaehler,$$))
                }endif
                Mach doch mal die Liste. Den Quellcode... da schauen wir noch. In 20.000+ Zeilen findet man nicht so leicht eine Antwort...
                Liste kommt, ist nur mit ein wenig Arbeit verbunden, wird wohl erst Dienstags was...

                @Marha:
                Muss chtime genau um 06:00:00 durchgeführt werden?
                Nein, so flott ist unsere Fußbodenheizung nicht, dass es da auf ein paar Sekunden ankommt, aber das mit den Sonnenstandsberechnungen alle 5 Minuten wußte ich bis heute ja auch nicht... werden die auch berechnet, wenn ich die gar nicht nutze?

                Auch sollte man mal mit den Performancezeiten spielen. Wie sind die bei Dir eingestellt?
                Die Performance-Zeiten sind noch auf den Standardwerten:
                Zykluszeit: 20 ms
                Busantwortzeit: 70 ms
                Webseitenserverrefresh: 15 s

                Im Moment habe ich selbst einiges an Funktion aus dem eibPC herausgenommen und letzlich nur eine einfache Visu mit Switches in Verwendung. Allein bei dieser Verwendung ist der eibPC schon mit mehr als 26 % ausgelastet, was ich als viel erachte, da eigentlich nur Schaltbefehle gesendet werden und auf Statusmeldungen vom Bus reagiert werden muss/soll.
                Ich finde es auch etwas schade, dass eine in meinen Augen einfache Visu soviel Performance zieht, erst recht, wenn kein Gerät darauf zugreift oder eine EibPC-Seite im Browser offen hat.

                Mir fehlt in der Doku ein Kapitel Richtung "best practice", was man sich erst selbst erarbeiten oder durch den Support erfragen muss. Für Anregungen/Erfahrungen/Tipps wäre ich dankbar.
                Das würde ich bei meinen aktuellen Problemen nur unterstützen... ich habe auch die cycle-Anweisung im Verdacht, Perfomance zu fressen. Zudem habe ich versucht die Anzahl der Änderungen, die pro Takt geprüft werden müssen, zu reduzieren, aber ob das wirklich Perfomance bringt, weiß ich nicht (daher auch der Vergleich mit "AktuelleZeitInSekundenZehner" (wird nur alle 10 Sekunden aktualisiert), ich habe auch noch "AktuelleZeitInSekunden", da ich mit den Timern vor vier Jahren nicht so glücklich war und mir so selbst Logiken drumherum gebaut habe). Aber wenn die Visu nicht so viel ziehen würde, wäre mir ja schon mal deutlich geholfen.

                Kommentar


                  #9
                  Zitat von georg123 Beitrag anzeigen
                  Code:
                  % Event: "St Bad OG Alles Licht-1/2/6":ERR_READ_GROUP_ADDRESS@2016-02-21 14:30:01
                  Ja, das schaut sehr gut aus.
                  Die Visu ist bei mir nur mit den Standard-Makros gebaut (einzig ein InitGA habe ich in der EnertexWebV3.lib zusäztlich eingebaut sowie das UmschaltShifter-Makro auch in einer globalen Variante bereitgestellt), die Dateien dazu habe ich mal angehängt:
                  Auch das kann es nicht sein.
                  Der Code ist recht simpel, ich habe den auch mal für eine halbe Stunde deaktiviert, das hat aber nichts gebracht (vielleicht einen Prozentpunkt). Ich
                  Also schließen wir das mal ebenso aus.
                  Ok, dass die Visu 20% bei 30 Seiten schluckt ist etwas viel, aber vielleicht auch noch im Rahmen. Allerdings sind deine Seite quasi leer, sodass ich das so nicht ganz nachvollziehen kann.
                  Allerdings frage ich mich, was bei Deinem EibPC 40% Performance frisst (ohne Visu). Was macht denn der noch außer Visu und den Logiken? Wie hoch ist Deine Telegrammlast? Kann die recht hoch sein? Eventuell vertraust Du dem Bus nicht und schickst ständig Anfragen und Wiederholungen?
                  22.000 Telegramme pro Tag sind zwar nur "0,5" pro Sekunde, aber das bedeutet aber auch, dass es wohl Zeiten mit 10..20 pro Sekunde geben kann. Kannst Du mal mit der ETS im Busmonitor beobachten? Gibt es eingefärbte Telegramme?
                  Das ursprüngliche Problem hatte ja mit der Anwesenheit zu tun. Wie wird die ermittelt? Kann es nicht sein, dass hier was schief läuft bzw. das Telegramm verloren geht? Gerade wenn dann im EibPC recht viel auf einmal angetriggert wird, wird die Buslast stoßweise hochgehen. Zudem wenn die Variablen irgendwie ständig auf Stati im Webserver schreiben, verursacht das sicher auch Last. Du kannst mal als Schnittstelle FT12 wählen und dann die Performance checken. In dem Fall läuft quasi dein Programm ohne Telegramme. Die CPU Usage ist im Übrigen seit letztem Neustart (des EiBPCs und nicht des Programms). Das ist auch noch zu berücksichtigen. Die alten Siemens Schnittstellen waren da recht zickig, v.a. bei vielen Telegrammen. Dann kommt es zum Re-Requests der Tunnelverbindungen, was die Verabeitung im EibPC sicher aufhält. Hast Du eine Telegrammratenbegrenzung im EibPC aktiviert?
                  Nein, so flott ist unsere Fußbodenheizung nicht, dass es da auf ein paar Sekunden ankommt, aber das mit den Sonnenstandsberechnungen alle 5 Minuten wußte ich bis heute ja auch nicht... werden die auch berechnet, wenn ich die gar nicht nutze?
                  Nein, das wurde falsch verstanden: Die Sonnenstandsberechnung wird nur einmalig beim Verändern der Daten vorgenommen (wird auch im EibStudio angezeigt). Die Aussage ist nur: Die Funktionen elavation() und azimith() werden alle 5 Minuten akutalisiert. Das passiert aber ohne große Performanceeinbuße. Wenn natürlich davon sehr viele weitere Berechnungen abhängen, kann das alle 5 Minuten etwas Rechenzeit in Anspruch nehmen.
                  Zykluszeit: 20 ms
                  Hier kannst Du etwas verbessern, indem Du auf 50 ms gehst, allerdings dürfte der Effekt nicht groß sein (das war früher bei einer ältern Firmware mal anders).
                  Ich finde es auch etwas schade, dass eine in meinen Augen einfache Visu soviel Performance zieht, erst recht, wenn kein Gerät darauf zugreift oder eine EibPC-Seite im Browser offen hat.
                  Da stimmt noch was nicht bzw. irgendwo ist ein performancefresser eingebaut, wäre meine Vermutung (30 Seiten sind nun auch nicht gerade wenig, aber das nur am Rande).
                  ich versucht die Anzahl der Änderungen, die pro Takt geprüft werden müssen, zu reduzieren, aber ob das wirklich Perfomance bringt, weiß ich nicht (daher auch der Vergleich mit "AktuelleZeitInSekundenZehner" (wird nur alle 10 Sekunden aktualisiert), ich habe auch noch "AktuelleZeitInSekunden", da ich mit den Timern vor vier Jahren nicht so glücklich war und mir so selbst Logiken drumherum gebaut habe).
                  Selbst wenn die Visu die 30% braucht, ist das wohl noch ok. Ich denke Deine Telegrammlast ist für Deinen Bus zu hoch, zumindest wäre das nun mein Ansatzpunkt.
                  (Eben nachgesehen): Auch hier im Hauptgebäude bei Enertex haben wir einen EibPC für die Visu, die da sehr aufgebohrt ist plus Logiken. Die Auslastung ist 69% (also hoch). Einen Verlust der Automatisierung haben wir nicht - das gäbe sonst oft Ärger. Soll heißen: 69% ist sicher nicht "gelangweilter EibPC", aber heißt nicht, dass automatisch was nicht funktioniert.
                  offizielles Supportforum für den Enertex® EibPC: https://knx-user-forum.de/eibpc/
                  Enertex Produkte kaufen

                  Kommentar


                    #10
                    Hallo, nur kurz, da ich gerade beim Geld verdienen bin:

                    Die CPU Usage ist im Übrigen seit letztem Neustart (des EiBPCs und nicht des Programms)
                    Diesen Umstand hatte ich bei all meinen Auslastungsangaben berücksichtigt.

                    Im Grunde merke ich auch keine direkten Auswirkungen mit den 69%, aber bei der Suche nach der chtime-Problem-Ursache ist mir das halt aufgfallen...

                    Kommentar


                      #11
                      Zitat von georg123 Beitrag anzeigen
                      Im Grunde merke ich auch keine direkten Auswirkungen mit den 69%, aber bei der Suche nach der chtime-Problem-Ursache ist mir das halt aufgfallen...
                      allles klar. Checke bitte mal das mit den Telegrammen.
                      offizielles Supportforum für den Enertex® EibPC: https://knx-user-forum.de/eibpc/
                      Enertex Produkte kaufen

                      Kommentar


                        #12
                        Hallo,

                        leider hatte ich die Tage nur sehr wenig Zeit, aber nun habe ich mal anstatt der IP die FTE-Schnittstelle verwendet, dort steigt mit zunehmender Dauer die Last von anfangs 54% auf 70% nach 12 Minuten... scheinbar zieht das Wegschreiben der Fehler auch Performance.

                        Nun zu meinen verwendeten Logiken, klingt für mich aber alles recht "normal"... aber ich lege mal mein Inneres offen ;-):
                        - UDP-Weitergabe aller Bus-Telegramme
                        - Mehfachbelegung von Schaltern (langer, kurzer, doppelter Tastendruck)
                        - Logik für Haus-Modus mit automatischen Übergang nach Zeiten und Anwesenheiten bestimmter Räume (alle wach, irgendjemand schläft, alle schalfen -> in Abhängigkeit davon ergibt sich ein anderes Verhalten diverser Dinge)
                        - automatische Abwesenheitserkennung über Präsenzmelder
                        - sonnen und Haus-Modus abhängige Rollladensteuerung
                        - Anwesenheits- und zeitabhängige Heizungssteuerung (die macht ja Probleme)
                        - Präsenzmelder-Lichtsteuerung
                        - Haus-Modus-abhängige Ansteuerung der Präsenzmelder-Licht-Schaltung (aktiv inaktiv)
                        - Erkennung ob Waschmaschinen, Trockner, Herd, 2 PCs oer Beamer an/aus sind (mit Benachrichtigung auf Display, cycle-Anweisungen für read-Strommessung)
                        - Display-Wechsel-Anzeige (siehe vorgeannten Punkt)
                        - UDP-Empfang für Display-Wechsel-Anzeige (für Anrufer)
                        - Aktivierung von PC-Strom bei längerer Nutzung am Tag für Sicherung
                        - Zirkulationspumpen-Schaltung
                        - Mittagsschlaf-Schaltung
                        - Zentraler-Lichtschalter-Logik für mehrere Räume
                        - Nachttlichtschaltung nach Haus-Modus
                        - Logik für jemand ist im OG/DG (für Abwesenheitserkennung)
                        - Weihnachtsbaumbeleuchtungslogik (draußen)
                        - Steuerung der elektrischen Leinwand
                        - Erkennung, ob Sat-Receiver Ein/Aus ist (per cycle-Ping)
                        - TCP-Aufruf für Ausschalten von SAT-Receiver
                        - Küchen-Android-PC-Logik inkl. Logik für Bildschirm und TCP-Kommunikation (nur EIN/AUS/Diashow an/Startbildschirm ein)
                        - Lüftungsanlagensteuerung
                        - Zentralstaubsauger-Steuerung mit Lüftungsklappe
                        - UDP-Anweisung für Telefonanlage in Nachtmodus
                        - Auslesen der Werte Eures KNX-Netzteils einmal in der Nacht

                        Das war es eigentlich... ich muss aber sagen, außer der schon weiter oben erwähnten cycle-Anweisung habe ich davon nichts im Verdacht, groß Performance zu fressen.


                        Kommentar


                          #13
                          Zitat von georg123 Beitrag anzeigen
                          Hallo,
                          leider hatte ich die Tage nur sehr wenig Zeit, aber nun habe ich mal anstatt der IP die FTE-Schnittstelle verwendet, dort steigt mit zunehmender Dauer die Last von anfangs 54% auf 70% nach 12 Minuten...
                          Das passt zusammen. Die FT12 benötigt bei hoher Telegrammlast mehr Performance (wegen einen aufwändigem Handshake) als die IP Schnittstelle.
                          scheinbar zieht das Wegschreiben der Fehler auch Performance.
                          Den Bezug versteh ich nicht. Ich kann nur noch mal das Obige ermpfehlen: Telegrammlastreduktion, Telegrammratenbegrenzung.
                          Ebenso ist hier auch nicht erkennbar, ob ein Anwesenheitstelegramm verloren geht. chtime ist für mehrere Stunden aktiv, daher sollte das auch kein Problem der "Schaltsekunde" sein. Ganz konkret würde ich erst mal das AnwesendAllgemeinFlag debuggen.
                          Nebenbei
                          Code:
                          (Wochentag == 1 or Wochentag == 2 or Wochentag == 3 or Wochentag == 4 or Wochentag == 5)
                          würde ich durch
                          Code:
                          dayofweek()<6
                          ersetzen.
                          Wir werden dieses Verhalten mit der Schaltsekunde in einer der nächsten Firmwareversionen zudem ändern: Im schlimmsten Fall würde bei extrem hoher Last der EibPC kurzfristig hinterherhinken.
                          offizielles Supportforum für den Enertex® EibPC: https://knx-user-forum.de/eibpc/
                          Enertex Produkte kaufen

                          Kommentar


                            #14
                            Hallo,

                            irgendwie scheine ich das mit der FT-Schnittstelle nicht ganz so verstanden zu haben:
                            Du kannst mal als Schnittstelle FT12 wählen und dann die Performance checken. In dem Fall läuft quasi dein Programm ohne Telegramme.
                            Ich dachte, ich sollte mal auf die FT-Schnittstelle wechseln (ohne dass ich dann Telegramme auf den Bus-Senden, ich habe ja nur die IP-Schnittstelle zum Bus), damit keine Telegramme vom Bus auf den EibPC einprasseln. Das habe ich gemacht und das oben skizzierte Verhalten festgestellt. Die Telegrammrate zu begrenzen, wäre für mich jetzt erst der nächste Schritt. Was ist denn dafür ein empfohlener Wert?

                            Code:
                            dayofweek()<6
                            ist nach meinem Verständnis nicht äquivalent zu
                            Code:
                            (Wochentag == 1 or Wochentag == 2 or Wochentag == 3 or Wochentag == 4 or Wochentag == 5)
                            da doch Sonntag = 0 ist...?
                            Aber natürlich hatte ich vorher mit dayofweek() und größer/kleiner/gleich Operatoren gearbeitet, da sind zuerst die oben skizzierten Probleme aufgetreten, daher wurde es dann der dargestellte Code (ich schrieb ja weiter oben von "verzweifelten Versuch" ;-)). Da es scheinbar daran nicht liegt, würde ich das auch wieder zurückbauen.

                            Was soll ich denn bzgl. AnwesenheitAllgemein debuggen? Der Status wird gesetzt, z.B gehen dann alle Displays von allen Schaltern wieder an, die Lüftungsanlage geht auf Stufe 2, das Licht im Flur geht an,... es funktioniert ja, ein sporadisches Fehlerverhalten gab es nur bei der Heizung und morgens um 6 Uhr ist das AnwesenheitAllgemein-Flag auf jeden Fall aktiv. Jeder Wechsel des Flags wird mir zudem per E-Mail gesendet, daher bekomme ich Fehlfunktionen dazu auch recht schnell mit...
                            Zuletzt geändert von georg123; 01.03.2016, 20:28. Grund: Erläuterung hinsichtlich nicht vorhandenem FT-Gerät ergänzt

                            Kommentar


                              #15
                              Zitat von georg123 Beitrag anzeigen
                              Hallo,
                              irgendwie scheine ich das mit der FT-Schnittstelle nicht ganz so verstanden zu haben:
                              Du hattest keine echte FT12 dran, oder wie? Wenn doch, ist die Last höher, wenn nicht bekommst Du ja keine Telegramme rein und daher wirst Du auch keine Belastung von den Telegrammen haben.
                              Die Telegrammrate zu begrenzen, wäre für mich jetzt erst der nächste Schritt. Was ist denn dafür ein empfohlener Wert?
                              bei einer Siemens haben wir immer 3/s eingestellt, Default wäre 7.
                              da doch Sonntag = 0 ist...?
                              Du hast recht.
                              Was soll ich denn bzgl. AnwesenheitAllgemein debuggen? Der Status wird gesetzt, z.B gehen dann alle Displays von allen Schaltern wieder an, die Lüftungsanlage geht auf Stufe 2, das Licht im Flur geht an,... es funktioniert ja, ein sporadisches Fehlerverhalten
                              Kannst Du nicht das Flag auf den Bus schreiben, sodass man sieht, es ist gesetzt? Außerdem müsste man mal schauen mit der ETS im Busmonitor, ob das Telegramm nicht einfach zerstört wird.
                              offizielles Supportforum für den Enertex® EibPC: https://knx-user-forum.de/eibpc/
                              Enertex Produkte kaufen

                              Kommentar

                              Lädt...
                              X