FHEM auf welcher Hardware

[Peteruser]

Hallo,
bei mir ist das ein J1900 Mainboard 8 GB und SSD. Reicht bei um die 10-12 W Leistungsaufnahme für meine gesammte IT Landschaft

Grüße Peter

[Damian]

Mein Umzugsprojekt von der Intel-Plattform mit SSD auf PI4 mit SD ist zunächst gescheitert - zu viele Hänger. Werde wohl einzeln vorgehen müssen, um die Übeltäter bei meiner umfangreichen Konfiguration ausfindig zu machen - CPU-Performance ist eben nicht alles.

In diesem Zusammenhang habe ich 1wire von OWX auf ESPEasy umgestellt, so läuft jetzt wenigstens mein Altsystem noch etwas runder

[Wernieman]

@andies

Load ist bei einem System <> Systemlast.

Load bedeutet Prozesse, welche auf IO Warten. Siehe auch https://de.wikipedia.org/wiki/Load

[LuckyDay]

Code Auswählen Erweitern

MiB Swap:    100,0 total,     67,5 free,     32,5 used.    425,7 avail Mem

Swap auf der SD  , kann man machen

Interresannt wie man die begrenzte Schreibfähigkeit der SD ignoriert

[amenomade]

Swap auf der SD  , kann man machen

Interresannt wie man die begrenzte Schreibfähigkeit der SD ignoriert

Woher weiss Du, dass seine swap Datei auf der SD Karte liegt?

Jedenfalls... Raspbian hat standardmässig eine swap Datei von 100MB und das ist gut so. Diese zu deaktivieren kann zwar die Lebensdauer der Karte verbessern (angenommen, dass das System permanent schreibt und liest, was nicht ubedingt der Fall ist: vielleicht wurde etwas seit Monaten geswapped und nie wieder gelesen), aber würde zu andere Problemen führen. Wenn das System swap benutzt hat, heisst es, dass ohne swap es gecrashed hätte, bzw. der Kernel hätte selbst Prozesse unfreundlich gekillt.

[andies]

@andies

Load ist bei einem System <> Systemlast.

Ja, ich weiss: aber meine Systemlast ist auch sehr gering:

Code Auswählen Erweitern


~ $ top
top - 19:56:45 up 5 days, 13:26,  3 users,  load average: 0,11, 0,09, 0,12
Tasks: 144 total,   1 running, 143 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,5 us,  0,3 sy,  0,0 ni, 99,2 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Mem :    926,1 total,     58,3 free,    422,8 used,    445,0 buff/cache
MiB Swap:    100,0 total,     67,2 free,     32,8 used.    434,0 avail Mem

PID USER      PR  NI    VIRT    RES    SHR S  CPU  MEM     TIMECOMMAND
12724 fhem      20   0  123152 109032   9768 S   2,3  11,5  21:36.90 perl
19723 pi        20   0   10340   3128   2576 R   0,7   0,3   0:00.11 top
315 avahi     20   0    6036   2792   2416 S   0,3   0,3   3:13.91 avahi-daemon
511 mysql     20   0  749948 195800   8148 S   0,3  20,6  24:37.88 mysqld
1 root      20   0   33744   5960   4852 S   0,0   0,6   0:18.69 systemd                                                                                                 

[Elektrolurch]

Hallo,

bin jetzt nach einem Tipp in diesem Thema auf einen ODROID H2 mit Intel umgezogen.
Mit einer SSD und einer HD braucht das Teil bei laufendem fhem und samba ca. 5 w. Das ist ja ok, finde ich.
Die Weboberfläche ist im Vergleich zu einem Cubieboard 2 deutlich schneller, auch fährt das ganze System in wenigen Sekunden hoch.
Portierung und ein gewisser Paralellbetrieb waren dann auch problemlos.
Nur das SYSMON - Modul ist wohl speziell für RPI geschrieben, da gibt es jetzt weder CPU - Infos wie Temperatur oder CPU-Auslastung...

Elektrolurch

[Damian]

Mein Umzugsprojekt von der Intel-Plattform mit SSD auf PI4 mit SD ist zunächst gescheitert - zu viele Hänger. Werde wohl einzeln vorgehen müssen, um die Übeltäter bei meiner umfangreichen Konfiguration ausfindig zu machen - CPU-Performance ist eben nicht alles.

In diesem Zusammenhang habe ich 1wire von OWX auf ESPEasy umgestellt, so läuft jetzt wenigstens mein Altsystem noch etwas runder

Nachdem ich das Problem gefunden habe, wichtig für Windowsumsteiger siehe: https://forum.fhem.de/index.php/topic,107864.msg1018728.html#msg1018728

läuft der kleine PI4 "with 627 defined entities" seit drei Wochen stabil und performant, die Intel-Plattform unter Windows wird noch für Entwicklung genutzt.

Mit 178 MB von 3,81 GB belegten Arbeitsspeicher ist noch sehr viel Luft nach oben. Eine 30 Euro USB-SSD sollte für SD-Kritiker auch kein Problem sein.

Fazit: Empfehlung für einen PI4-Umstieg

[Gisbert]

Hallo,

mein HP T610 mit 4 GB RAM, 250 GB SSD mit Fhem, UniFi-Controller (also im laufenden Betrieb) braucht 11 Sekunden für diesen Befehl:

Code Auswählen Erweitern

perl -e 'my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'
Nicht schlecht, aber auch nicht sonderlich gut.

Viele​ Grüße​ Gisbert​

[Elektrolurch]

Mal eine Frage zur begrenzten Schreibkapazität von SD-Karten und einem möglichen Workaround:

Bei den Intel basierten Systemen hat man ja die >Möglichkeit das Boot - device schon im BIOS einzustellen.
Das geht m.W.n. bei den Arm-basierten Systemen ja nicht, bzw. das mit den Booten ist ja nicht ganz so trivial.
Meistens wird doch erst einmal nachgesehen, ob eine SD-Karte eingesteckt ist (wie beim cubieboard).
Um diese möglichst wenig durch Schreibvorgänge zu belasten könnte man auf der SD - Karte nur ein minimales Linux installieren und in der fstab folgende Zeile einfügen:

Code Auswählen Erweitern


/dev/sda1 /  ext4 defaults,noatime 0 2
[/cod]

Und auf das /dev/sda1 (SSD oder HD) ein komplettes Linux installieren.

Was spricht gegen so eine Vorgehensweise? Oder funktioniert das überhaupt nicht?

Elektrolurch


[Wernieman]

Dann solltest Du auf der SD_Card nur das boot-Device setzen und gleich im root auf die SSD zeigen. Dann schreibst Du definitiv nie auf die SD (abgesehen von der Installation)

@Gisbert
auch mein FHEM System ergibt mit der perl Zeile "nur" 11 Sekunden ...
(Mein Arbeitsrechner dagegen 3 .. da sind ind er CPU aber auch Welten dazwischen)

Diese Zeile ist aber auch nur ein reiner CPU (perl) Check. Es wird eben geprüft, wie schnell der Rechner in perl von 1 bis 100000000 zählen kann. Ob jetzt das IO-Device langsam oder schnell ist, ist dabei irrelevant ...

[Damian]

Vielleicht kommt ja mal irgendwann das UEFI in die originale Firmware, siehe : https://www.heise.de/newsticker/meldung/UEFI-Firmware-fuer-den-Raspberry-Pi-4-und-3-4663269.html

Unabhängig von der Hardware sollte man paar Minuten apptime laufen lassen. So habe ich bei mir einen der Übeltäter mit bis zu 8 Sekunden Blockade ausfindig gemacht. OWX brauchte bei mir ca. 1 Sekunde-Abfragezeit pro Device, bei 8 Sensoren, wenn sie hintereinander abgefragt wurden (gleiche Intervalldefinition) konnten es dann 8 Sekunden werden. Zunächst habe ich es auf Windows (auf Intel) geschoben. Dort habe ich die Intervalle unterschiedlich gewählt, um die Blockaden zu entzerren. Unter 30 Sekunden Abfrageintervall bin ich allerdings bei keinem Sensor gegangen. Leider war nach der Umstellung auf PI4 das gleiche Bild. Daraufhin habe ich 1-wire auf ESPeasy umgestellt. Das war schnell erledigt (einfach 1-wire-Bus vom USB-Adapter auf ESP2866 umgehängt), dort habe ich jetzt alle Sensoren auf 15 Sekunden Abfrageintervall stehen und keinerlei Hänger im System - per apptime nachweisbar.

Was jetzt am meisten Zeit braucht, ist bei mir der HM-LAN-Adapter mit ca. 150 mSek, aber das ist eher normal und nicht als Blockade zu sehen

Auch hier kann man sagen: besseres Reaktionsverhalten, trotz langsamerer Hardware

[Beta-User]

Evtl. hätte es gereicht, OWX auf einen asynchronem Modus umzustellen; ich habe diesen Teil aus ähnlichen Gründen noch in der "vor-Asynchronen Zeit"  auf MySensors@RS485 umgestellt und nutze seitem auch in der Regel irgendwelche MCU's, um die gemessenen Werte an FHEM zu senden.

Die 1 Sek. kommt übrigens daher, dass der Sensor erst die Anweisung braucht, dass er messen soll, und dann erst abgefragt werden kann - wie früh, hängt auch von der Auflösung ab (max. Auflösung = 12=750ms für die Messung) braucht man in der Regel gar nicht...

Ansonsten hatten wir zum Thema SSD an USB auch schon Fälle, in denen das zu Problemen geführt hatte, wenn nämlich die Platte kurz weg war; Linux mag Verbindungsunterbrechungen zu Systemplatten nämlich nicht besonders, jedenfalls afaik...

Mein T620 braucht übrigens zwischen 9 und 11 Sekunden, aber die reine Prozessorleistung ist für FHEM eigentlich völlig egal. Wichtiger sind mir z.B. ausreichend viele, vernünftige USB-Anschlüsse (da hängen u.A. diverse MySensors-Gateways dran).

[Damian]

Ich krame mal den alten Thread wieder hervor, weil die Hardwarefrage immer wieder im Raum steht. Zumal der Raspi 5 kommt.

Z. Zt. läuft fhem bei mir noch auf einem Raspi 4, da ich aber noch einen Windows-Server auf einem NUC 8i5 daneben laufen hatte, habe ich mir gedacht das kann man sicherlich auch eleganter und kostengünstiger mit einem Rechner lösen. Zuvor hatte ich mehrere Jahre fhem unter Windows laufen, aber diese Lösung war suboptimal. Angeregt durch den Beitrag von Andrea Spieß https://www.youtube.com/watch?v=rXc_zGRYhLo habe ich kurzer Hand Proxmox auf den NUC drauf gespielt und dort u. a. Windows und Debian als VM-System installiert.

Der Rechner braucht im Idle (in den VMs passiert ja nicht viel) um die 6 Watt, also nicht mehr als mein Raspi 4 mit einer externen SSD. Dabei steck dort eine 2 TB und eine 4 TB SSD drin (WLAN wurde abgeschaltet)

Der Performancetest:

perl -e 'my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'

liefert in einer VM ca. 2 Sekunden (man müsste den Test langsam auf Millisekunden umstellen )

Wenn man bedenkt, dass Minirechner mit potenter Hardware inzwischen verhältnismäßig günstig zu bekommen sind (doppelte Performance meines alten NUCs mit Speicher und SSD für ca. 300 Euro) und nicht viel mehr als ein Raspi an Strom brauchen, sind sie eine gute Alternative zum Raspi, vor allem wenn man noch etwas mehr als nur fhem dauerhaft laufen lassen möchte.

Zusätzlich kommen die Vorteile eines VM-Systems insb. was die Flexibilität angeht noch hinzu.

[betateilchen]

Angeregt durch den Beitrag von Andrea Spieß

man muss nicht jeden Vornamen gendern...