Hallo und Guten Morgen
mein Hardwareserver ist leider ausgestiegen und ich bin am überlegen, ob es mittlerweile bessere Hardware als den Cubietruck mit SSD gibt.Ich habe bisher Homematik, IT und etliche LED Variationen in Betrieb gehabt.Ein zweiter Cubitruck läuft für die Alexa Version und für die Homematik IP Geräte hatte/habe ich die HM CCu2
Hat jemand Erfahrungen dazu?
Eine Info wäre toll
Ich wünsche einen schönen Tag
Rock Pi könnte interessant sein:
https://www.reichelt.de/index.html?ACTION=446&LA=2&q=rock%20pi%204
läuft auch mit ssd (NVMe).
Ich habe den aber nicht, daher kann ich keine Erfahrungen beisteuern.
Ich würde Dir mittlerweile BareBones Empfehlen (Intel NUC, Zotac (mein Favorit, etc...)
Allerdings sind die dann doch etwas teurer (mit ~260 für ein Zotac CI329 sollte man rechnen), dafür aber auch deutlich stabiler/schneller als ein Pi
Ich würde ebenfalls BareBones empfehlen, e.g ich hatte mit einem RasPi3 immer folgende Probleme:
- das Sonos Modul lief schlecht und blockierte
- alle 3-4 Tage Abstürze
- Fehlermeldung wegen zu wenig Speicher ......
Langfristig machts einfach mehr Spass und ist wesentlich stabiler.
Ich habe einen Intel NUC mit i3 und würde ihn immer wieder kaufen. Darauf Proxmox mit einzelnen LXC für jeden Dienst. Übersichtlich und einzeln updatebar. Backups laufen wie flüssige Butter.
Zitat von: gloob am 29 April 2019, 17:28:58
Ich habe einen Intel NUC mit i3 und würde ihn immer wieder kaufen. Darauf Proxmox mit einzelnen LXC für jeden Dienst. Übersichtlich und einzeln updatebar. Backups laufen wie flüssige Butter.
Welchen NUC?
Aktuell wird man wohl zum aktuellen Modell greifen, am besten BEH im Namen mit Platz für eine 2.5" Platte. Ich habe das Vorgängermodell als Arbeitsrechner.
https://www.amazon.de/Intel-NUC8i3BEH-Mainboard-Generation-Processors/dp/B07JB2M5JS/ref=sr_1_6?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=nuc&qid=1556555054&s=computers&sr=1-6
Und wer Proxmox einsetzen will sollte schauen das die CPU Hyper-V unterstützt.
Und gerne mal über den Tellerrand schauen, also nicht immer gleich "Intel NUC"
Nachteil von NUC: Sie haben einen Lüfter ....
Zitat von: Wernieman am 29 April 2019, 21:59:45
Und gerne mal über den Tellerrand schauen, also nicht immer gleich "Intel NUC"
Nachteil von NUC: Sie haben einen Lüfter ....
Viel gravierender als der Lüfter, den man übrigens beim nuc i3 kaum hört, ist der überteuerte Preis eines nucs.
Bei mir läuft FHEM seit paar Jahren darauf:
https://www.notebooksbilliger.de/pc+lenovo+ideacentre+200+01ibw+90fa003dge+intel+celeron+3215u
hat mich 150 € neu gekostet.
Ich habe Fhem auch auf einem Raspberry 3 am laufen, ich habe noch eine zbox id90 hier, die liegt seit über einem Jahr im Schrank und wird nicht mehr benutzt.
Ist es ein großer Aufwand mit Fhem auf die zbox umzuziehen?
Zitat von: elmer am 29 April 2019, 23:17:20
Ich habe Fhem auch auf einem Raspberry 3 am laufen, ich habe noch eine zbox id90 hier, die liegt seit über einem Jahr im Schrank und wird nicht mehr benutzt.
Ist es ein großer Aufwand mit Fhem auf die zbox umzuziehen?
Zotac hat linux im download. Sollte also laufen. installiere einfach mal debian drauf. Wenn das läuft hast den größten Schritt bezogen auf Kompatibilität gemacht.
Wenn sie "älter" ist, läuft FHEM bestimmt darauf. Meine CI327 (gib es nicht mehr) ist "damals" eigentlich für Windows gedacht, läuft aber super mit Linux ...
Für ein FHEM-Testsystem hatte ich mir mal ein ACEPC AK1 zugelegt ... Celeron-Prozessor, somit zwar deutlich unter einem i3 auf durchaus ausreichend und gemessen am Preis sehr interessant.
Debian installiert, Treiber für LAN und WLAN musste ich extra aus dem Internet laden der Rest wurde problemlos erkannt. Das Teil läuft erstaunlich stabil und auch ruhig.
Intern ist nur eMMC installiert (nicht der schnellste), es ist aber noch Platz für ne mSATA-SSD und in den Erweiterungseinsatz passt ne 2,5 HDD oder SSD (per USB3 angebunden).
https://www.amazon.de/dp/B075RZT2PW
Unter den EinplatinenComputer ist der Cubietruck aber schon mit die beste Lösung bzgl SSD-Anbindung. Dafür gibt es vernünftige Gehäuse, die auch gleich noch ein Akku als "USV" mit unterbringen können. Alternative evtl noch der Odroid H1.
Alles andere was ich kenne hat meist kein SATA oder es bleibt eine "optische Bastellösung". Vom Dauerbetrieb auf SD-Karte würde ich abraten, vor allem wenn man noch eine Datenbank drauf laufen lassen will.
Dann ich auch noch:
https://www.esm-computer.de/fujitsu-esprimo-q520-core-i5-4590t-2-0-ghz-1017227/
+ SSD-CD-Caddy und zweite SSD rein
+ Proxmox
= macht bei mir erstmal "alles" (Squeezeserver, PiHole, FHEM, SAMBA)
(Win 10 Lizenz hab ich eh gebraucht).
Alternative wäre ein neues gebrauchtes ThinkPad kaufen (T450s) und dann das alte T420s als Server aller Art nehmen. Aber der Vorteil der integrierten USV bei weniger Leistung wars mir nicht wert.
hast du auch mal geschrieben was für Voraussetzungen du hast?
Wenn du ein 19" Rack im Keller hast würde ich zb. nicht zum Pi oder Cubie raten.
Dann kann ich dir diese Seite empfehlen, das habe ich (bis auf die NAS Platten aber mit 2x SSD für Raid1 für die SystemPlatte) auch aufgebaut in einem 19Rack 1HE
https://www.technikaffe.de/anleitung-404-nas_basic_3.0_mit_passiv_gekuehltem_apollo_lake_4_kern_prozessor
Man sollte sich auch mal die Frage stellen, wie viel ist einem der Dauerläufer wert.
Bei 10 Watt (Idle), kostet der Spaß ohne PV-Anlage ca. 25 Euro pro Jahr.
Der NUC i3 kommt z. B bei potenter Hardware mit ca. 5 Watt (Idle) aus.
Nur mal als Anmerkung ... haben wir hier nicht schon einige Diskussionen über die Hardware?
Stromverbrauch der zbox id90 schwankt zwischen 19 und 25 Watt wenn der Rechner nichts macht. Auf der Box ist Win 10 installiert, das ist zu viel, wenn Debian installiert ist kann man mit einem geringeren Verbrauch rechnen oder wird dieser auch so hoch sein?
Es kommt auf die Konfiguration drauf an und was man laufen lässt.
Also Pauschal nicht beantwortbar.
Ok, dann wird die id90 wohl nicht geeignet sein, diese war einige Jahre mein Mediaplayer und da wurde nie etwas installiert außer Windows und Kodi.
Ich würde es probieren ... Du kannst doch einfach mal Debian (oder besser Ubuntu-Server) drauflegen und nachmessen ...
Und selbst wenn die Stromkosten 25 Euro im Jahr sind, ein neuer kostet mehr als 3 Jahre, d.h. es würde sich erst in 3 Jahrn lohnen, mit einem "neuen" anzufangen.
Und von der Umweltbelastung ... besser ein alt-gerät weiter nutzen als ein neues kaufen ... (solange eben die Energiebilanz (s.o.) stimmt)
Ich würde die GPIOs vermissen ohne Pi. Der steht im Wohnzimmer und da sind einige Sensoren dran, 2 Bewegungsmelder SR501, IR senden und empfangen und über I2C BMP180, SHT21, TSL2561. Das ist nicht leicht preiswert zu ersetzen. Und wenn auch KODI auf dem Mini-PC laufen soll, fehlt das CEC-Modul.
Ich muß gestehen, das ich ein produktives FHEM-System und KODI auf einem PI .... zum Gruseln finde ... (individuelle persönliche Meinung)
Zitat von: Wernieman am 30 April 2019, 19:30:43
FHEM-System und KODI auf einem PI
Davon war nicht die Rede, sondern im Zuge einer möglichen Migration auf einen Mini-PC.
Man muß bei einem Umstieg berücksichtigen, ob einem danach etwas fehlt.
Es spricht nichts dagegen einen Raspi für bestimmte Aufgaben herzurichten, ich habe meinen alten wieder reaktiviert - als Testsystem, Model B braucht noch ca. 1,5 Watt (Idle) - produziert also kaum laufende Kosten.
Was Preis/Leistung angeht, verliert ein Raspi allerdings schnell:
Beispiel:
PI- Vollausstattung: https://www.amazon.de/ABOX-Raspberry-Ultimatives-Starterkit-aus-Schaltnetzteil/dp/B07DDCRFP6/ref=sr_1_1_sspa?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=2ZJH9OPE0NM6G&keywords=raspberry+pi+3+b%2B&qid=1556650739&s=gateway&sprefix=rasp%2Caps%2C172&sr=8-1-spons&psc=1
kostet schnell 80 €
Dagegen Intel-Plattform:
https://www.amazon.de/Intel-NUC-BOXNUC6CAYH-Computer-CELERON/dp/B01MSZTD8N/ref=sr_1_1?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=nuc+3455&qid=1556650831&s=gateway&sr=8-1
+
https://www.amazon.de/Kingston-KVR16LS11-Arbeitsspeicher-Non-ECC-204-pin/dp/B00CQ35GYE/ref=pd_bxgy_147_img_2/258-5760406-2743531?_encoding=UTF8&pd_rd_i=B00CQ35GYE&pd_rd_r=81923bda-6b79-11e9-b2bb-656476ee377c&pd_rd_w=mEkwO&pd_rd_wg=5rq25&pf_rd_p=449f5fd6-8f81-46b7-aa57-ca96572671a1&pf_rd_r=BRYSZ5MVAFYK6VP0FRC5&psc=1&refRID=BRYSZ5MVAFYK6VP0FRC5
+
https://www.amazon.de/Crucial-BX500-CT240BX500SSD1Z-Internes-5-Zoll/dp/B07G3KRZBX/ref=sr_1_8?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=ssd&qid=1556650881&s=computers&sr=1-8
kostet zwar etwas mehr als das Doppelte, dafür hat man eine stabile Plattform mit SSD und mit Power von sechs Raspis.
Edit: Auch die Stromkosten halten sich in Grenzen: 5 Watt (Intel) gegen 3,5 Watt (3B+)
Jemand schon Erfahrung mit https://www.gearbest.com/mini-pc/pp_009920577490.html?wid=1433363#goodsDetail ? Na... ok... bis auf die 15W
Zitat von: amenomade am 30 April 2019, 21:52:03
Jemand schon Erfahrung mit https://www.gearbest.com/mini-pc/pp_009920577490.html?wid=1433363#goodsDetail ? Na... ok... bis auf die 15W
Wenn ich es mit meiner vorherigen Intel-Konfiguration vergleiche, dann verliert dieses System, denn
kostet nicht weniger, braucht vermutlich mehr als 5 Watt im Leerlauf, hat nur 128 GB SSD und CPU ist schwächer:
https://www.cpubenchmark.net/compare/Intel-Celeron-1007U-vs-Intel-Celeron-J3455/1847vs2875
Hat aber 8 USB Ports, was mir ein externes USB Hub mit eigener Stromversorgung sparen würde.
Zitat von: amenomade am 30 April 2019, 22:10:52
Hat aber 8 USB Ports, was mir ein externes USB Hub mit eigener Stromversorgung sparen würde.
Willst du dir im Ernst eine sechs Jahre alte CPU zulegen ;)
Naja... bin noch auf der Suche nach der ideale Konfiguration ;)
Zitat von: amenomade am 30 April 2019, 22:45:59
Naja... bin noch auf der Suche nach der ideale Konfiguration ;)
Klar, ist ein schwieriges Thema und auch kein Neues. Jeder hat seine Präferenzen und die sind ja für seine Entscheidung von Bedeutung.
Wenn z. B. jemand eine PV-Anlage hat, den stört vielleicht auch nicht, wenn sein System 30 Watt im Leerlauf verbraucht.
Wenn man sich aber über Stromkosten Gedanken machen muss, dann sollte man beachten, dass üblicherweise ältere Systeme nicht so sparsam waren, wie heutige.
Ich gehe davon aus, dass das alte Schätzchen (Mainboard ca. 5 Jahre alt) insgesamt über 10 Watt im Leerlauf verbraucht.
Wobei auch immer meine "obige" Abschätzung gilt.
Wenn man das System im "Schrank liegen hat" sieht es auch wieder anders aus. Bei einem Neukauf würe ich für FHEM nicht mehr auf einen PI setzen.
Btw:
Auch die GPIOs vom PI werden überschätze. Ich persönlich würde (bei neuen Projekten) dann lieber auf eine Plattform wie esp8266 setzen, also trennen von Hardwareansteuerung und FHEM-Server.
Ich würde den Umzug ja evtl. wagen, ich bin mir aber nicht sicher ob ich das als Laie hinbekomme. Meine größte Sorge ist das fhem dann nicht mehr richtig läuft.
Ich habe viele Monate und Nächte damit verbracht alles einzubinden damit es läuft, ich weiß schon gar nicht welche Pakete ich alles neu installieren muß damit alles in fhem wieder geht.
Welchen Server sollte ich installieren, Ubuntu 18.04.2 live Server amd64 oder Ubuntu 19.04 live Server amd64?
Gibt es Probleme wenn ich bisher Debian installiert hatte und nun auf Ubuntu wechsle?
Ob sich ein Umstieg auf andere Hardware, zumindest aus Sicht der Performance lohnt, kann man ja mal mit der Single-Core-Leistung unter Perl vergleichen.
Der Aufruf auf der Konsole:
perl -e 'my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'
ergibt bei mir:
Raspi 3B 2B 44 Sekunden.
Intel 3215U 8 Sekunden.
Intel i3-7100U 5 Sekunden
Ich schätze der Raspi 3B+ braucht für die hundert Millionen Durchläufe um die 37 20 Sekunden.
Die Plattenperformance (gegen eine SSD) vergleichen wir ein anderes Mal ;)
Zitat von: Damian am 01 Mai 2019, 15:38:40
Raspi 3B 44 Sekunden.
Da hast Du ein anderes Problem: bei mir auf dem Raspi ergibt das 27 ;)
Zitat von: Damian am 01 Mai 2019, 15:38:40
Ob sich ein Umstieg auf andere Hardware, zumindest aus Sicht der Performance lohnt, kann man ja mal mit der Single-Core-Leistung unter Perl vergleichen.
Der Aufruf auf der Konsole:
perl -e 'my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'
ergibt bei mir:
Raspi 3B 44 Sekunden.
Intel 3215U 8 Sekunden.
Intel i3-7100U 5 Sekunden
Ich schätze der Raspi 3B+ braucht für die hundert Millionen Durchläufe um die 37 Sekunden.
Die Plattenperformance (gegen eine SSD) vergleichen wir ein anderes Mal ;)
7 Sekunden auf einem i3-3217U unter Proxmox im LXC. :D
Zitat von: amenomade am 01 Mai 2019, 17:44:35
Da hast Du ein anderes Problem: bei mir auf dem Raspi ergibt das 27 ;)
Und du hast auch das vorletzte Pi-Modell? Wenn es sich um das aktuelle Modell 3B+ handelt, dann ist die aktuelle Pi-CPU besser als ich dachte .
Das ist der hier: https://www.amazon.de/gp/product/B01MQK27CV/
Zitat von: amenomade am 01 Mai 2019, 19:56:23
Das ist der hier: https://www.amazon.de/gp/product/B01MQK27CV/
OK. Ich habe gerade feststellen müssen, dass mein Modell noch etwas älter ist.
Mit
cat /sys/firmware/devicetree/base/modelbekomme ich:
Raspberry Pi 2 Model B Rev 1.1Also noch das zweier Model.
Dann wird das aktuelle Modell 3B+ wohl bei knapp über 20 Sekunden landen.
Raspberry Pi 3 Model B Rev 1.2habe ich
Aber gut... trotzdem mit dem NUC unvergleichbar ;)
Wenn man einen Raspberry Pi 3 hat und wechselt auf einen 3b+ kann man dann einfach die SD Karte umstecken und alles läuft wieder?
Zitat von: Damian am 01 Mai 2019, 15:38:40
Ob sich ein Umstieg auf andere Hardware, zumindest aus Sicht der Performance lohnt, kann man ja mal mit der Single-Core-Leistung unter Perl vergleichen.
Der Aufruf auf der Konsole:
perl -e 'my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'
...
Ein Intel® Core™ i3-7100 Dual-Core mit 3,9 GHz Prozessor braucht knappe 3Sekunden.
FHEM läuft in einer VM auf einem QNAP. Die VM läuft auf einem RAID1 mit 2x 1TB SSD und maximal 32GB RAM, wobei der FHEM VM nur eine CPU und 4GB RAM (DDR4) zugewiesen sind.
Nur zur Info.
Gruß
Mathze
Zitat von: t1me2die am 02 Mai 2019, 07:35:01
Ein Intel® Core™ i3-7100 Dual-Core mit 3,9 GHz Prozessor braucht knappe 3Sekunden.
FHEM läuft in einer VM auf einem QNAP.
Nur zur Info.
Gruß
Mathze
Ich denke, dass das schon ziemlich das Minimum ist, was man mit der heutigen Technik erreichen kann. Ich habe es auf die schnellste heutige CPU hochgerechnet: bei 2,7 Sekunden dürfte Schluss sein.
Auf der anderen Seite reden wir von FHEM, wenn sonst nichts darauf läuft, reicht ein aktueller raspi 3B+ vollkommen aus, wenn die fehlende Anbindung an eine Platte nicht wäre ;)
In diesem Zusammenhang viel mir ein, dass ich da noch etwas zum Testen in der Schublade hatte.
Falls jemand Power eines Raspis mit USV und HDD auf Intel-Basis sucht, mein alter FHEM-Rechner: https://forum.fhem.de/index.php/topic,100181.0.html
https://forum.fhem.de/index.php/topic,99124.0.html
Ciao, -MN
Zitat von: Damian am 03 Mai 2019, 19:36:52
In diesem Zusammenhang viel mir ein, dass ich da noch etwas zum Testen in der Schublade hatte.
Falls jemand Power eines Raspis mit USV und HDD auf Intel-Basis sucht, mein alter FHEM-Rechner: https://forum.fhem.de/index.php/topic,100181.0.html
... die Renaissance der Schrank-Notebooks :) ... .mein Fhem läuft auch auf einem alten Notebook. Geringer Stromverbrauch, "eh-da-Hardware", viel performanter als Raspi und Akku als USV. Das einzige was mir fehlt ist ein Watchdog, gebaut bevor Intel die itco-wdt einbauten.
Und was vieles vereinfacht, Tastatur und Bildschirm gleich mit dabei.
Hallo zusammen,
habe schon seit ein paar Jahren das cubieboard 2 im Einsatz. Braucht nur 1,2 W und ich nutze den Sata - Anschluß für ein Backup-System im Netzwerk.
Einziger Nachteil: Der Kernel von Igor ist schon recht alt....
Daher wollte ich ein weiteres System aufsetzen und wenn dann alles läuft mit fhem umziehn.
Hat jemand Erfahrungen mit den Nachfolgeboards cubieboard 3 - 7 schon gemacht?
Wenn ja, mit welcher Debian - Version und welchem Kernel?
Elektroluch
Der Cubietruck (Cubieboard 3) war mich mich das beste Gerät, da es dafür vernünftige Gehäuse gibt mit Platz für SSD und Pufferbatterie gibt. Auch wird das Teil aktuell (noch) von armbian supported.
Bei den späteren Modellen war SATA imho wieder abgeschafft oder nur noch via USB implementiert worden.
Zitat von: Damian am 01 Mai 2019, 15:38:40
perl -e 'my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'
ergibt bei mir:
Raspi 3B 2B 44 Sekunden.
Intel 3215U 8 Sekunden.
Intel i3-7100U 5 Sekunden
Ich schätze der Raspi 3B+ braucht für die hundert Millionen Durchläufe um die 37 20 Sekunden.
Hier noch eine interessante Alternative:
Odroid HC1: 9 Sekunden
Wird auch gut mit aktuellem Armbian-OS unterstützt. Direkter Anschluss für eine SATA-HDD/SSD, reiner Server, Konsole nur über seriellen Port.
https://www.pollin.de/p/odroid-hc1-einplatinen-computer-fuer-nas-und-cluster-anwendungen-810766
Ein guter Tipp, benutze bei dem cubieboard die Grafik sowieso nicht.
Schade nur, dass der wohl nur einen USB-Anschluß hat, denn ich habe für fhem zwei CULs angeschlossen. SATA über USB3 ist hier mit 300 MBs angegeben, dass schafft der cubie nach meiner Messung auch so gerade.
Mal sehen, wie eine Ersetzungsstrategie aussehen könnte. Danke für den Tipp.
Elektrolurch
Ich habe vor einiger Zeit meine Diskstation 214Play gegen eine 218+ (+8Gb Ram) ausgetauscht. Da diese sowieso wg. den Kameraaufzeichnungen läuft, habe ich eine Virtuelle Maschine mit Debian 9 drauf laufen. Das ist um einiges stabiler als mit dem Raspi3. Zudem ist es eine tolle Sache, einfach Snapshots oder ein Klon von der VM zu erstellen.
Selbst der USB Bluetooth Dongle wird durchgereicht und funktioniert einwandfrei in der virtuellen Umgebung :)
Gruß,
SteRa
@roedert
wieviel "Saft" gönnt sich denn das Teil?
also odroid-hc1 plus ssd?
ich suche ja auch irgendwie noch einen Ersatz für den Cubie3
Zitat von: roedert am 07 Mai 2019, 14:24:53
Hier noch eine interessante Alternative:
Odroid HC1: 9 Sekunden
Wird auch gut mit aktuellem Armbian-OS unterstützt. Direkter Anschluss für eine SATA-HDD/SSD, reiner Server, Konsole nur über seriellen Port.
https://www.pollin.de/p/odroid-hc1-einplatinen-computer-fuer-nas-und-cluster-anwendungen-810766
Zitat von: Damian am 01 Mai 2019, 15:38:40
Ob sich ein Umstieg auf andere Hardware, zumindest aus Sicht der Performance lohnt, kann man ja mal mit der Single-Core-Leistung unter Perl vergleichen.
Der Aufruf auf der Konsole:
perl -e 'my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'
ergibt bei mir:
Raspi 3B 2B 44 Sekunden.
Intel 3215U 8 Sekunden.
Intel i3-7100U 5 Sekunden
Ich schätze der Raspi 3B+ braucht für die hundert Millionen Durchläufe um die 37 20 Sekunden.
Die Plattenperformance (gegen eine SSD) vergleichen wir ein anderes Mal ;)
Ich habe gerade einen Raspi 4 installiert und gemessen, Ergebnis:
Raspi 4: 9 SekundenAlso ca. doppelt so schnell wie ein Raspi 3.
Kommt langsam an mein bisheriges FHEM-Intel-System mit Intel 3215U (hat allerdings nur zwei Kerne)
Gemessen wird natürlich nur die Single-Kernleistung, die aber für FHEM wesentlich ist.
Wenn nur die Stabilität vergleichbar wäre ... ;o)
Zitat von: Wernieman am 24 Januar 2020, 21:08:58
Wenn nur die Stabilität vergleichbar wäre ... ;o)
Naja Fhem bekommt im dauerbetrieb alles kaputt Hd's Sd's SSD's vorallem Netzgeräte
Solche Hardware Leichen kannste bei mirhaben
Also das hat FHEM hier noch nie geschafft ...
Berufmäßig habe ich schon diverse kaputte Harware gehabt, aber mit Stabilität meinte ich eher die Softwarestabilität.
Zitat von: Damian am 02 Mai 2019, 07:40:30
Auf der anderen Seite reden wir von FHEM, wenn sonst nichts darauf läuft, reicht ein aktueller raspi 3B+ vollkommen aus, wenn die fehlende Anbindung an eine Platte nicht wäre ;)
Das wollte ich gerade fragen: Was habt Ihr denn da alles am Laufen? Ich habe einen load von
top - 21:20:34 up 4 days, 14:50, 3 users, load average: 0,32, 0,28, 0,17
Tasks: 145 total, 1 running, 144 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0,1 us, 0,3 sy, 0,0 ni, 99,6 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
MiB Mem : 926,1 total, 63,8 free, 430,5 used, 431,8 buff/cache
MiB Swap: 100,0 total, 67,5 free, 32,5 used. 425,7 avail Mem und das ist noch viel, Standard sind eher 0,0irgendwas. Deshalb würde ich nie umziehen, nur die SD Karte, die werde ich mal regelmäßig wechseln (obwohl die letzte doch nicht kaputt war, wie ich dachte).
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
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 :)
@andies
Load ist bei einem System <> Systemlast.
Load bedeutet Prozesse, welche auf IO Warten. Siehe auch https://de.wikipedia.org/wiki/Load (https://de.wikipedia.org/wiki/Load)
Zitat von: andies
MiB Swap: 100,0 total, 67,5 free, 32,5 used. 425,7 avail Mem
Swap auf der SD :o , kann man machen
Interresannt wie man die begrenzte Schreibfähigkeit der SD ignoriert
Zitat von: fhem-hm-knecht am 26 Januar 2020, 18:46:53
Swap auf der SD :o , 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.
Zitat von: Wernieman am 26 Januar 2020, 17:46:41
@andies
Load ist bei einem System <> Systemlast.
Ja, ich weiss: aber meine Systemlast ist auch sehr gering:
~ $ 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
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
Zitat von: Damian am 26 Januar 2020, 16:08:15
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
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:
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
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:
/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
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 ...
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
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).
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.
Zitat von: Damian am 14 Oktober 2023, 13:27:27Angeregt durch den Beitrag von Andrea Spieß
man muss nicht jeden Vornamen gendern...
Zitat von: betateilchen am 14 Oktober 2023, 13:35:39Zitat von: Damian am 14 Oktober 2023, 13:27:27Angeregt durch den Beitrag von Andrea Spieß
man muss nicht jeden Vornamen gendern...
Solange es nicht Andrea Berg ist ;)
Zitat(man müsste den Test langsam auf Millisekunden umstellen ;))
z.Bsp. indem man "use Time::HiRes qw(time);" davorhaengt.
Zitat von: rudolfkoenig am 14 Oktober 2023, 13:41:19Zitat(man müsste den Test langsam auf Millisekunden umstellen ;))
z.Bsp. indem man "use Time::HiRes qw(time);" davorhaengt.
perl -e 'use Time::HiRes qw(time);my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'liefert: 2.20171403884888
Hallo Damian,
ich nutze einen gebraucht gekauften Futro S740 mit 16 GB Arbeitsspeicher und einer 1 TB SSD (letzteres neu eingebaut), auf dem Proxmox läuft. Je eine VM hab ich für Fhem, Pi-hole und den UniFi-Controller (mein eigenes Netz hinter der Fritzbox).
Ich bin äußerst zufrieden damit, vor allem auch mit den Backup-Möglichkeiten von Proxmox. Davor hatte ich einen HP T610. Der Futro S740 ist gemessene 5-6mal schneller bei einem Verbrauch von 10 W vs. 35 W beim HP T610.
Viele Grüße Gisbert
ja, da hat sich einiges getan, hier ein Powervergleich der CPU´s:
https://www.cpubenchmark.net/compare/3159vs3299vs4883/Intel-Celeron-J4105-vs-Intel-i5-8259U-vs-AMD-Ryzen-5-5560U
von links nach rechts:
Deine, meine und eine in so einem Minipc: https://www.amazon.de/TRIGKEY-Desktop-PC-Type-C-Radeon-Gaming/dp/B0BR5M9K28/ref=sr_1_1_sspa?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=2N2VBZH29BUC8&keywords=5560U&qid=1697314852&sprefix=5560u%2Caps%2C224&sr=8-1-spons&sp_csd=d2lkZ2V0TmFtZT1zcF9hdGY&psc=1
Die tuckern alle mehr oder minder mit 10 Watt vor sich hin.
Darf ich mal unqualifiziert zwischenfragen? Smarthome ist doch sicherlich nicht die einzige Anwendung für "Server zu Hause"? Wer hat zusätzlich noch ein NAS (für Backup, etc.) daneben stehen?
Ich hab mir einen DELL T30 in den Keller gestellt, darauf ein ESXi (ich brauche auch noch Windows-VMs) und dann in unterschiedlichen VMs NAS (mit OMV), Smarthome und Nextcloud (alles mit Debian) installiert.
Wahrscheinlich hätte man da auch Docker verwenden können.
Am Ende habe ich eine physische Maschine für alles, damit sollte auch der Stromverbrauch im Rahmen bleiben.
jm2c
Ich kann hier nur den schon mehrfach geposteten Vorschlag empfehlen, ein altes Notebook als FHEM-Server einzusetzen !
Ich hatte auf dem RasPi3 vor einigen Jahren laufend Performance-Probleme mit FHEM, die auf einen Schlag erledigt waren, nachdem ich auf ein altes Intel 2-Kern CPU-Notebook mit SSD und ubuntu-Server migriert hatte. :)
Braucht vielleicht mit abgeschaltetem Screen ein paar Watt mehr, aber:
- vielfache Performance
- keine SD-Card-Probleme mehr
- und die USV ist (mit neuem Akku) auch mit dabei
- vermutlich sind alte Notebooks in 2023 immer noch leichter zu beschaffen als RasPi's ;)
Wobei ein Dauerversorgtes Notebook leicht einen Aufgeblähten Akku bekommen kann. Gab mal extra Laptops (oder Ersatzakkus) für solche Anwendungsfälle, die nicht dazu neigen.
Binn immer noch ein Freund der "Kleinstrechner", wie NUC, Zotac oder ...
Zitat von: pcbastler am 17 Oktober 2023, 21:52:13Darf ich mal unqualifiziert zwischenfragen? Smarthome ist doch sicherlich nicht die einzige Anwendung für "Server zu Hause"? Wer hat zusätzlich noch ein NAS (für Backup, etc.) daneben stehen?
Ich hab mir einen DELL T30 in den Keller gestellt, darauf ein ESXi (ich brauche auch noch Windows-VMs) und dann in unterschiedlichen VMs NAS (mit OMV), Smarthome und Nextcloud (alles mit Debian) installiert.
Wahrscheinlich hätte man da auch Docker verwenden können.
Am Ende habe ich eine physische Maschine für alles, damit sollte auch der Stromverbrauch im Rahmen bleiben.
jm2c
Vor paar Tagen habe ich, wie bereits hier geschrieben, auf einem NUC 8i5 das Proxmox installiert. Von der Performance, der Bedienbarkeit von Proxmox und dem niedrigen Verbrauch des Minirechners war ich begeistert.
Leider schmierte das System immer wieder ab. Auch diverse Versuche durch Biosänderungen das Proxmox stabil zu bekommen waren nicht erfolgreich.
Installiert hatte ich dort eine Debian-VM für FHEM (FHEM lief aber noch nicht), eine Debian-VM mit OpenmediaVault als NAS mit SMB für Windowsrechner im Heimnetz und eine Windows-VM mit Windows 11.
Mein Verdacht ist, dass die Windows-VM das Problem bei mir darstellt, ich habe sie nun gestoppt - seit zwei Tagen läuft das System stabil. Leider ist das keine Option für mich.
Ich habe gerade das ESXi-ISO heruntergeladen und probiere mein Glück damit.
Sollte die Umgebung stabil laufen, möchte ich weitere VMs dort installieren:
eine zweite FHEM-Instanz für Entwicklung, Nextcloud, RaspberryMatic, ggf. Automatisierung der Konkurrenz zum Ausprobieren und was mir sonst so einfällt.
Die Power des kleinen Minis mit 6 TB SSDs und 32 GB Hauptspeicher sollte dafür ausreichen.
Zitat32 GB Hauptspeicher
Probiere mal für Debugzwecke mit weniger Hauptspeicher. Viele Minnirechner sind für weniger Hauptspeicher zertifiziert.
Und wenn der Rechner "abschmiert" .. gibt es Einträge bei den üblichen Verdächtigen? syslog/kern.log etc?
Offiziell sind beim 8i5beh 2x16 GB 2400 DDR4 zugelassen (eingebaut sind 2 x Crucial RAM 16GB DDR4 3200 MHz CL22 (oder 2933 MHz oder 2666 MHz) Laptop Arbeitsspeicher CT16G4SFRA32A)
Der Rechner lief zuvor stabil mit diesen Riegeln unter Windows.
kernel.log kann auf dem Proxmox-System nicht finden. In anderen Logs sehe ich auch nichts Verdächtiges.
Hallo Damian,
ich nutze einen NUC7 und einen NUC11 jeweils mit Proxmox und ohne Probleme. Ich lese auch aktiv im Proxmox-Forum mit.
Wenn es da um NUCs geht, sind die ersten Fragen die, ob 1) das letzte aktuelle BIOS installiert ist und ob 2) VT-d und VT-x aktiviert sind.
Meine beiden NUCs laufen mit dem 8.0.4 und dem Kernel 6.2.16-15-pve #1.
Übrigens bin ich von ESXi umgestiegen, weil gerade das Thema lxc micht gereizt hat - so habe ich bspw. verschiedene Services containerisiert statt alles in eine VM zu packen. Außerdem wollte ich des Spieltriebs wegen einen Cluster aufbauen und sogar Pseudo-HA realisieren - das alles geht mit einen ESXi-free nicht.
Edit: das Kernel.log findest du in /var/log/kern.log
Ich habe mal zwischendurch ESXi (mit free-key) installiert. Lief absolut stabil. Habe dort Debian installiert. Allerdings klappte eine Windows 11 Installation schon mal nicht, da ESXi (ohne vCenter) den TPM-Chipsatz des NUC nicht unterstützt - schade eigentlich.
Mir gefällt die Sache mit den lxc-Containern bei Proxmox auch ganz gut. Ich habe jetzt das BIOS aktualisiert und damit auch die Einstellungen zurückgesetzt, VT-d und VT-x waren immer schon aktiviert.
Nach dem Motto: die Hoffnung stirbt zuletzt - schauen wir mal, wann der nächste "freeze" kommt.
übrigens, kern.log gibt es bei mir unter /var/log nicht
Ich habe mal im Proxmox-Forum etwas herumgestöbert, man findet direkt bei den neusten Threads diverse Probleme mit der Stabilität des Systems -vor allem beim Upgrade auf die 8er-Version. Bei mir wurde es leider nicht besser. Bin erst mal auf die 7er-Version gegangen, mal schauen ob es besser wird.
Sehr spannender Thread. Ich habe seit 2 Jahren einen Raspi 4 mit einer unterdessen recht umfangreichen FHEM Installation. z.T. dauert der Seitenaufbau 4-5 Sekunden. Wenn ich mir die Optionen ansehe, so würde ich nicht mehr auf den Pi zurückgreifen. Die PIN Leiste brauche ich kaum und die Performance ist nicht so berauschend. Der Pi 5 soll wesentlich schneller sein, braucht dann allerdings auch mehr Strom (gemäss heise/ c't).
Pi 4 braucht 9s für den "perl -e 'my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'" Test, mein Uralt-Intel Server mit Intel(R) Pentium(R) CPU G2020 2.9Ghz nur 4s.
ZitatUralt-Intel Server
Verwendung von alter Hardware 24*7 sollte man sich immer Gründlich überlegen. Ein aktueller Mini PC mit Intel® Celeron® N4505 liegt bei c.a. 140,- + RAM und SSD (schnelle Suche, +- ist möglich). Wenn die Kiste dann 4-5 Jahre läuft, kann die Stromersparnis die Kosten wieder rausholen oder sogar überkompensieren.
Zitat von: ansgru am 19 Oktober 2023, 12:01:17Sehr spannender Thread. Ich habe seit 2 Jahren einen Raspi 4 mit einer unterdessen recht umfangreichen FHEM Installation. z.T. dauert der Seitenaufbau 4-5 Sekunden. Wenn ich mir die Optionen ansehe, so würde ich nicht mehr auf den Pi zurückgreifen. Die PIN Leiste brauche ich kaum und die Performance ist nicht so berauschend. Der Pi 5 soll wesentlich schneller sein, braucht dann allerdings auch mehr Strom (gemäss heise/ c't).
Pi 4 braucht 9s für den "perl -e 'my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'" Test, mein Uralt-Intel Server mit Intel(R) Pentium(R) CPU G2020 2.9Ghz nur 4s.
Aus diesem Grund habe ich mir ein "refurbished ThinkCenter M900" für wenig Geld gegönnt.
Damit habe ich neben fhem den MySQL-Server vom alten NAS mit umziehen können.
Zudem läuft Grafana, Wekan etc... alles sehr geschmeidig...
Seitenaufbau - insbesondere wenn graphen dabei sind - hing bei mir meist an der SQl-Performance. Der Stromverbrauch ist vergleichsweise höher als beim PI, aber dafür laufen auch viel mehr Dienste. Das NAS dient aktuell nur für Backups.
Ich hab da noch potential einiges an Verbrauchern zu sparen - wie z.B. die HM-CCU. Aber dafür brauch ich erstmal Zeit.
perl -e 'use Time::HiRes qw(time);my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)' liefert mir
2.8207 s
Ok, dann mache ich mal mit 8) :
NUC7i5: 2.35804009437561 s
NUC11i7: 1.42791604995728 s
lxc-Container, in dem FHEM auf dem NUC11 läuft, 2 Kerne und 4GB zugewiesen: 1.43110513687134 s
pi3: 21.3367218971252 s 8)
Da geht mehr: Pi2B 37 sec ;D
Beim sparsamen LAPTOP (Lenovo B50-30 mit Celeron N2815) komme ich auf ca. 6-7 Watt ohne bzw. dunkler Bildschirm - immerhin. Dürfte aber vermutlich mit seinen 2 Kernen kein berauschender Performancegewinn (macht 12sec für die Schleife) sein.
Könnte mir einen Einsatz als Kombi: FHEM-Server und Anzeige Board vorstellen. Aber mehrere VM oder Container sicher nicht.
Architektur: x86_64
CPU Operationsmodus: 32-bit, 64-bit
Adressgrößen: 48 bits physical, 48 bits virtual
Byte-Reihenfolge: Little Endian
CPU(s): 32
Liste der Online-CPU(s): 0-31
Anbieterkennung: AuthenticAMD
BIOS-Anbieterkennung: Advanced Micro Devices, Inc.
Modellname: AMD Ryzen 9 5950X 16-Core Processor
BIOS-Modellname: AMD Ryzen 9 5950X 16-Core Processor Unknown CPU @ 3.4GHz
BIOS-Prozessorfamilie: 107
Prozessorfamilie: 25
Modell: 33
Thread(s) pro Kern: 2
Kern(e) pro Sockel: 16
Sockel: 1
Stepping: 2
Übertaktung: aktiviert
Skalierung der CPU(s): 73%
Maximale Taktfrequenz der CPU: 5083,3979
Minimale Taktfrequenz der CPU: 2200,0000
BogoMIPS: 6787,36
Markierungen: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc
rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand
lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx
cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsave
opt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale
vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl umip pku ospke vaes vpclmulqdq rdpid overflow_recov succor
smca fsrm
Virtualisierungsfunktionen:
Virtualisierung: AMD-V
Caches (Gesamtsumme):
L1d: 512 KiB (16 Instanzen)
L1i: 512 KiB (16 Instanzen)
L2: 8 MiB (16 Instanzen)
L3: 64 MiB (2 Instanzen)
NUMA:
NUMA-Knoten: 1
NUMA-Knoten0 CPU(s): 0-31
Schwachstellen:
Gather data sampling: Not affected
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Retbleed: Not affected
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Mitigation; Retpolines, IBPB conditional, IBRS_FW, STIBP always-on, RSB filling, PBRSB-eIBRS Not affected
Srbds: Not affected
Tsx async abort: Not affected
FHEM Test und Demo läufen als Container in einem 3 Node Kubernetes Cluster
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
k8s-control01 Ready control-plane 195d v1.26.7 10.6.6.22 <none> Debian GNU/Linux 11 (bullseye) 5.10.0-23-amd64 containerd://1.6.22
k8s-node01 Ready <none> 195d v1.26.7 10.6.6.31 <none> Debian GNU/Linux 11 (bullseye) 5.10.0-23-amd64 containerd://1.6.22
k8s-node02 Ready <none> 195d v1.26.7 10.6.6.35 <none> Debian GNU/Linux 11 (bullseye) 5.10.0-23-amd64 containerd://1.6.22
NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
container-registry private-repository-7f8f64867d-cdfjm 1/1 Running 0 47h 172.20.58.234 k8s-node02 <none> <none>
fhem-demo fhem-7c4d757fb-7chnp 1/1 Running 0 68m 172.20.58.199 k8s-node02 <none> <none>
fhem-testing t-fhem01-5d8fb46d6b-55wf5 1/1 Running 1 (32h ago) 32h 172.20.58.243 k8s-node02 <none> <none>
jumphost-production ssh-jumphost-8795b7fdb-p5lvr 1/1 Running 0 2d1h 172.20.85.227 k8s-node01 <none> <none>
jumphost-production web-nginx-reverseproxy-d6bdc4957-nmqhn 1/1 Running 0 8d 172.20.58.215 k8s-node02 <none> <none>
kaniko fhem-docker 0/1 Completed 0 80m 172.20.58.193 k8s-node02 <none> <none>
keycloak-production keycloak-0 1/1 Running 1 (14d ago) 14d 172.20.58.205 k8s-node02 <none> <none>
kochbuch recipes-8459f475d5-9b5t8 2/2 Running 2 (14d ago) 14d 172.20.58.207 k8s-node02 <none> <none>
kube-system calico-kube-controllers-949d58b75-k9g5t 1/1 Running 11 (14d ago) 69d 172.20.246.81 k8s-control01 <none> <none>
kube-system calico-node-f6cwt 1/1 Running 11 (14d ago) 69d 10.6.6.22 k8s-control01 <none> <none>
kube-system calico-node-n5bzd 1/1 Running 11 (14d ago) 69d 10.6.6.31 k8s-node01 <none> <none>
kube-system calico-node-sv4gk 1/1 Running 12 (14d ago) 69d 10.6.6.35 k8s-node02 <none> <none>
kube-system coredns-754b6c9d98-2dpvt 1/1 Running 8 (14d ago) 19d 172.20.246.82 k8s-control01 <none> <none>
kube-system coredns-754b6c9d98-pxncm 1/1 Running 9 (14d ago) 68d 172.20.246.80 k8s-control01 <none> <none>
kube-system etcd-k8s-control01 1/1 Running 20 (14d ago) 77d 10.6.6.22 k8s-control01 <none> <none>
kube-system kube-apiserver-k8s-control01 1/1 Running 4 (14d ago) 14d 10.6.6.22 k8s-control01 <none> <none>
kube-system kube-controller-manager-k8s-control01 1/1 Running 23 (14d ago) 77d 10.6.6.22 k8s-control01 <none> <none>
kube-system kube-proxy-42blq 1/1 Running 15 (14d ago) 69d 10.6.6.22 k8s-control01 <none> <none>
kube-system kube-proxy-68wlv 1/1 Running 15 (14d ago) 69d 10.6.6.35 k8s-node02 <none> <none>
kube-system kube-proxy-mzztz 1/1 Running 14 (14d ago) 69d 10.6.6.31 k8s-node01 <none> <none>
kube-system kube-scheduler-k8s-control01 1/1 Running 23 (14d ago) 77d 10.6.6.22 k8s-control01 <none> <none>
kube-system metrics-server-69bc768f87-r9kqm 1/1 Running 1 (14d ago) 14d 172.20.85.245 k8s-node01 <none> <none>
metallb-system controller-68bf958bf9-c86lm 1/1 Running 1 (14d ago) 14d 172.20.85.249 k8s-node01 <none> <none>
metallb-system speaker-hwqrq 1/1 Running 190 (14d ago) 195d 10.6.6.22 k8s-control01 <none> <none>
metallb-system speaker-qhv8r 1/1 Running 99 (14d ago) 195d 10.6.6.31 k8s-node01 <none> <none>
metallb-system speaker-rmdcv 1/1 Running 99 (14d ago) 195d 10.6.6.35 k8s-node02 <none> <none>
nfs-client nfs-client-provisioner-7cc79b4877-6qrmq 1/1 Running 1 (14d ago) 14d 172.20.85.243 k8s-node01 <none> <none>
paperless-production paperless-paperless-ngx-9cf5ccd96-cp62h 1/1 Running 0 14d 172.20.85.248 k8s-node01 <none> <none>
paperless-production paperless-redis-master-0 1/1 Running 1 (14d ago) 14d 172.20.58.206 k8s-node02 <none> <none>
stirlingpdf-testing stirlingpdf-79986c979d-vsf7z 1/1 Running 0 12d 172.20.85.199 k8s-node01 <none> <none>
traefik-system traefik-5554c9fdc4-5j4q6 1/1 Running 0 4d22h 172.20.58.226 k8s-node02 <none> <none>
tuxnetwiki-production tuxnetwiki-dokuwiki-64d6df4bf9-b5pcf 1/1 Running 0 7d 172.20.85.222 k8s-node01 <none> <none>
Der Produktive FHEM läuft aktuell noch als LX Container
VMID Status Lock Name
200 running p-checkmk
201 running p-fhem
202 running p-jitsi
205 running p-stun
206 running p-debmirror
207 running puppetmaster
208 running p-gitserver
210 running p-matrix
212 running p-psql01
213 running p-nextcloud
214 running p-mail
220 stopped p-jumphost
221 running p-mastodon
222 running p-ncsignal
ZitatAMD Ryzen 9 5950X
Wie lange braucht die "dicke Kiste" fuer die Schleife (s.o)?
Bei welchem Verbrauch?
Zitat von: rudolfkoenig am 19 Oktober 2023, 16:56:23ZitatAMD Ryzen 9 5950X
Wie lange braucht die "dicke Kiste" fuer die Schleife (s.o)?
Bei welchem Verbrauch?
Ich schätze mal 1.5 Sekunden im besten Fall. Die Stromkosten dürften dafür nicht unerheblich sein.
Zitat von: Ralli am 19 Oktober 2023, 14:03:37Ok, dann mache ich mal mit 8) :
NUC7i5: 2.35804009437561 s
NUC11i7: 1.42791604995728 s
lxc-Container, in dem FHEM auf dem NUC11 läuft, 2 Kerne und 4GB zugewiesen: 1.43110513687134 s
Proxmox 7er läuft bei mir seit Stunden stabil, die 8er blieb teilweise schon beim Booten hängen. Leider braucht die Schleife im debian lxc-Container fast 10 Sekunden, während sie in der 8er Version die Geschwindigkeit vom Host hatte, also 2,2 Sekunden.
Also nix mit lxc unter Proxmox 7, bei VMs wird dagegen die Hostpower der Kerne durchgereicht - schade eigentlich.
Zitat von: rudolfkoenig am 19 Oktober 2023, 16:56:23ZitatAMD Ryzen 9 5950X
Wie lange braucht die "dicke Kiste" fuer die Schleife (s.o)?
Bei welchem Verbrauch?
Also ich hab hier nen Ryzen 9 3900X mit 12 Kernen als Desktop-Rechner.
Macht unter Windows mit StrawberryPerl: 2.71870112419128
Dabei gönnt er sich ohne Last (Monitor dabei...) so 120W. Mit CPU Benchmark gerne 220 W. Da lief die GraKa aber noch nicht mit ;-)
Zitat von: Damian am 19 Oktober 2023, 17:46:52Zitat von: Ralli am 19 Oktober 2023, 14:03:37Ok, dann mache ich mal mit 8) :
NUC7i5: 2.35804009437561 s
NUC11i7: 1.42791604995728 s
lxc-Container, in dem FHEM auf dem NUC11 läuft, 2 Kerne und 4GB zugewiesen: 1.43110513687134 s
Proxmox 7er läuft bei mir seit Stunden stabil, die 8er blieb teilweise schon beim Booten hängen. Leider braucht die Schleife im debian lxc-Container fast 10 Sekunden, während sie in der 8er Version die Geschwindigkeit vom Host hatte, also 2,2 Sekunden.
Also nix mit lxc unter Proxmox 7, bei VMs wird dagegen die Hostpower der Kerne durchgereicht - schade eigentlich.
Welche Netzwerkkarte hast Du verbaut? Und schau mal bitte unter /var/log/kern.log oder journalctl -kr was dort so steht. So Auffälligkeiten.
Zitat von: rudolfkoenig am 19 Oktober 2023, 16:56:23ZitatAMD Ryzen 9 5950X
Wie lange braucht die "dicke Kiste" fuer die Schleife (s.o)?
Bei welchem Verbrauch?
Da habe ich mich ehrlich gesagt nie drum gekümmert ;D
Zitat von: CoolTux am 19 Oktober 2023, 19:42:52Zitat von: Damian am 19 Oktober 2023, 17:46:52Zitat von: Ralli am 19 Oktober 2023, 14:03:37Ok, dann mache ich mal mit 8) :
NUC7i5: 2.35804009437561 s
NUC11i7: 1.42791604995728 s
lxc-Container, in dem FHEM auf dem NUC11 läuft, 2 Kerne und 4GB zugewiesen: 1.43110513687134 s
Proxmox 7er läuft bei mir seit Stunden stabil, die 8er blieb teilweise schon beim Booten hängen. Leider braucht die Schleife im debian lxc-Container fast 10 Sekunden, während sie in der 8er Version die Geschwindigkeit vom Host hatte, also 2,2 Sekunden.
Also nix mit lxc unter Proxmox 7, bei VMs wird dagegen die Hostpower der Kerne durchgereicht - schade eigentlich.
Welche Netzwerkkarte hast Du verbaut? Und schau mal bitte unter /var/log/kern.log oder journalctl -kr was dort so steht. So Auffälligkeiten.
Die Netzwerkkarte ist: Intel® Ethernet Connection I219-V
Ich glaube mit der dieser Hardware wird das nix mit Proxmox, auch die 7er Version hat sich verabschiedet.
kern.log hat die gleichen Meldungen wie journalctl:
-- Journal begins at Thu 2023-10-19 09:32:01 CEST, ends at Thu 2023-10-19 20:36:46 CEST. --
Oct 19 19:05:41 pve pvedaemon[1046]: <root@pam> end task UPID:pve:0000437E:0007EAD6:65315CFA:vncproxy:105:root@pam: OK
Oct 19 19:05:44 pve pvedaemon[1045]: <root@pam> starting task UPID:pve:00005207:0009D78C:653161E7:vncproxy:105:root@pam:
Oct 19 19:05:44 pve pvedaemon[20999]: starting vnc proxy UPID:pve:00005207:0009D78C:653161E7:vncproxy:105:root@pam:
Oct 19 19:07:32 pve pveproxy[1053]: worker 11761 finished
Oct 19 19:07:32 pve pveproxy[1053]: starting 1 worker(s)
Oct 19 19:07:32 pve pveproxy[1053]: worker 21319 started
Oct 19 19:07:34 pve pveproxy[21318]: got inotify poll request in wrong process - disabling inotify
Oct 19 19:12:27 pve pvedaemon[1046]: worker exit
Oct 19 19:12:27 pve pvedaemon[1044]: worker 1046 finished
Oct 19 19:12:27 pve pvedaemon[1044]: starting 1 worker(s)
Oct 19 19:12:27 pve pvedaemon[1044]: worker 22161 started
Oct 19 19:13:16 pve pvedaemon[1045]: <root@pam> successful auth for user 'root@pam'
Oct 19 19:13:37 pve pvedaemon[1045]: <root@pam> end task UPID:pve:00005207:0009D78C:653161E7:vncproxy:105:root@pam: OK
Oct 19 19:13:37 pve pveproxy[21318]: worker exit
Oct 19 19:17:01 pve CRON[22994]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Oct 19 19:17:01 pve CRON[22995]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Oct 19 19:17:01 pve CRON[22994]: pam_unix(cron:session): session closed for user root
Oct 19 19:18:14 pve pvedaemon[1045]: <root@pam> successful auth for user 'root@pam'
Oct 19 19:21:44 pve pvedaemon[1045]: <root@pam> starting task UPID:pve:00005D29:000B4ECE:653165A8:vncproxy:102:root@pam:
Oct 19 19:21:44 pve pvedaemon[23849]: starting lxc termproxy UPID:pve:00005D29:000B4ECE:653165A8:vncproxy:102:root@pam:
Oct 19 19:21:44 pve pvedaemon[1047]: <root@pam> successful auth for user 'root@pam'
Oct 19 19:22:05 pve pvedaemon[1045]: <root@pam> end task UPID:pve:00005D29:000B4ECE:653165A8:vncproxy:102:root@pam: OK
Oct 19 19:22:23 pve pvedaemon[1047]: <root@pam> starting task UPID:pve:00005DD4:000B5DD9:653165CF:qmdestroy:101:root@pam:
Oct 19 19:22:23 pve pvedaemon[24020]: destroy VM 101: UPID:pve:00005DD4:000B5DD9:653165CF:qmdestroy:101:root@pam:
Oct 19 19:22:23 pve pvedaemon[1047]: <root@pam> end task UPID:pve:00005DD4:000B5DD9:653165CF:qmdestroy:101:root@pam: OK
Oct 19 19:23:00 pve pvedaemon[22161]: <root@pam> starting task UPID:pve:00005E3F:000B6C43:653165F4:qmstart:103:root@pam:
Oct 19 19:23:00 pve pvedaemon[24127]: start VM 103: UPID:pve:00005E3F:000B6C43:653165F4:qmstart:103:root@pam:
Oct 19 19:23:00 pve systemd[1]: Started 103.scope.
Oct 19 19:23:00 pve systemd-udevd[24139]: Using default interface naming scheme 'v247'.
Oct 19 19:23:00 pve systemd-udevd[24139]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Oct 19 19:23:00 pve kernel: device tap103i0 entered promiscuous mode
Oct 19 19:23:00 pve systemd-udevd[24155]: Using default interface naming scheme 'v247'.
Oct 19 19:23:00 pve systemd-udevd[24155]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Oct 19 19:23:00 pve systemd-udevd[24155]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Oct 19 19:23:00 pve systemd-udevd[24139]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Oct 19 19:23:00 pve kernel: vmbr0: port 5(fwpr103p0) entered blocking state
Oct 19 19:23:00 pve kernel: vmbr0: port 5(fwpr103p0) entered disabled state
Oct 19 19:23:00 pve kernel: device fwpr103p0 entered promiscuous mode
Oct 19 19:23:00 pve kernel: vmbr0: port 5(fwpr103p0) entered blocking state
Oct 19 19:23:00 pve kernel: vmbr0: port 5(fwpr103p0) entered forwarding state
Oct 19 19:23:00 pve kernel: fwbr103i0: port 1(fwln103i0) entered blocking state
Oct 19 19:23:00 pve kernel: fwbr103i0: port 1(fwln103i0) entered disabled state
Oct 19 19:23:00 pve kernel: device fwln103i0 entered promiscuous mode
Oct 19 19:23:00 pve kernel: fwbr103i0: port 1(fwln103i0) entered blocking state
Oct 19 19:23:00 pve kernel: fwbr103i0: port 1(fwln103i0) entered forwarding state
Oct 19 19:23:00 pve kernel: fwbr103i0: port 2(tap103i0) entered blocking state
Oct 19 19:23:00 pve kernel: fwbr103i0: port 2(tap103i0) entered disabled state
Oct 19 19:23:00 pve kernel: fwbr103i0: port 2(tap103i0) entered blocking state
Oct 19 19:23:00 pve kernel: fwbr103i0: port 2(tap103i0) entered forwarding state
Oct 19 19:23:00 pve pvedaemon[22161]: <root@pam> end task UPID:pve:00005E3F:000B6C43:653165F4:qmstart:103:root@pam: OK
Oct 19 19:32:27 pve pvedaemon[1047]: <root@pam> successful auth for user 'root@pam'
-- Boot 6b2a8bba6753410caf030f7429fbfa23 --
Oct 19 20:21:17 pve kernel: Linux version 5.15.102-1-pve (build@proxmox) (gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) >
Oct 19 20:21:17 pve kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.15.102-1-pve root=/dev/mapper/pve-root ro quiet
Oct 19 20:21:17 pve kernel: KERNEL supported cpus:
Oct 19 20:21:17 pve kernel: Intel GenuineIntel
Oct 19 20:21:17 pve kernel: AMD AuthenticAMD
Oct 19 20:21:17 pve kernel: Hygon HygonGenuine
Oct 19 20:21:17 pve kernel: Centaur CentaurHauls
Oct 19 20:21:17 pve kernel: zhaoxin Shanghai
Oct 19 20:21:17 pve kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Oct 19 20:21:17 pve kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Oct 19 20:21:17 pve kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Oct 19 20:21:17 pve kernel: x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
Oct 19 20:21:17 pve kernel: x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
Oct 19 20:21:17 pve kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
Oct 19 20:21:17 pve kernel: x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64
Oct 19 20:21:17 pve kernel: x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64
Oct 19 20:21:17 pve kernel: x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format.
Oct 19 20:21:17 pve kernel: signal: max sigframe size: 2032
Oct 19 20:21:17 pve kernel: BIOS-provided physical RAM map:
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009efff] usable
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x000000000009f000-0x00000000000fffff] reserved
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x0000000000100000-0x0000000079b2bfff] usable
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x0000000079b2c000-0x0000000079f97fff] reserved
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x0000000079f98000-0x000000007a014fff] ACPI data
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x000000007a015000-0x000000007a0c5fff] ACPI NVS
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x000000007a0c6000-0x000000007ab4ffff] reserved
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x000000007ab50000-0x000000007ac0dfff] type 20
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x000000007ac0e000-0x000000007ac0efff] usable
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x000000007ac0f000-0x000000007fffffff] reserved
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x00000000e0000000-0x00000000efffffff] reserved
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x00000000fe000000-0x00000000fe010fff] reserved
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x00000000fed00000-0x00000000fed03fff] reserved
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x0000000100000000-0x000000087dffffff] usable
Oct 19 20:21:17 pve kernel: NX (Execute Disable) protection: active
Oct 19 20:21:17 pve kernel: efi: EFI v2.70 by American Megatrends
Oct 19 20:21:17 pve kernel: efi: ACPI 2.0=0x79fb1000 ACPI=0x79fb1000 TPMFinalLog=0x7a050000 SMBIOS=0x7a9a4000 SMBIOS 3.0=0x7a9a3000 MEMATTR=0x77c23018 ESR>
Oct 19 20:21:17 pve kernel: secureboot: Secure boot disabled
Oct 19 20:21:17 pve kernel: SMBIOS 3.2.1 present.
Oct 19 20:21:17 pve kernel: DMI: Intel(R) Client Systems NUC8i5BEH/NUC8BEB, BIOS BECFL357.86A.0092.2023.0214.1114 02/14/2023
Oct 19 20:21:17 pve kernel: tsc: Detected 2300.000 MHz processor
Oct 19 20:21:17 pve kernel: tsc: Detected 2299.968 MHz TSC
Oct 19 20:21:17 pve kernel: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
Oct 19 20:21:17 pve kernel: e820: remove [mem 0x000a0000-0x000fffff] usable
Oct 19 20:21:17 pve kernel: last_pfn = 0x87e000 max_arch_pfn = 0x400000000
Oct 19 20:21:17 pve kernel: x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT
Oct 19 20:21:17 pve kernel: last_pfn = 0x7ac0f max_arch_pfn = 0x400000000
Oct 19 20:21:17 pve kernel: esrt: Reserving ESRT space from 0x000000007ab4cf98 to 0x000000007ab4cfd0.
...
Der letzte Eintrag vor dem erzwungenen Neustart war um 19:32:27, die Meldungen beim Neustart um 20:21:17 und folgende waren auch alle unauffällig.
Da steht ja so gar nichts drin im Log was auffällig ist. MEM Test war Unauffällig?
Zitat von: CoolTux am 19 Oktober 2023, 21:15:33Da steht ja so gar nichts drin im Log was auffällig ist. MEM Test war Unauffällig?
ja, memtest86 ist mit 0 Fehlern durchgelaufen.
Als letztes probiere ich noch statt der NVMe-SSDs (EV0 970 plus 2tb bzw. EVO 980 pro 2tb) das System auf einer Sata-SSD (EVO 870 4tb) zu installieren.
ansonsten mit "stress" mal das System durchtesten.
Zitat von: Wernieman am 20 Oktober 2023, 08:18:00ansonsten mit "stress" mal das System durchtesten.
Einen Hardwaredefekt würde ich eher ausschließen, der Rechner lief vorher drei Jahre lang unter Windows ohne Probleme. Zum Teil bleibt er schon kurz nach dem Booten stehen, da wird er noch nicht mal warm.
Zitat von: Damian am 19 Oktober 2023, 17:46:52Proxmox 7er läuft bei mir seit Stunden stabil, die 8er blieb teilweise schon beim Booten hängen. Leider braucht die Schleife im debian lxc-Container fast 10 Sekunden, während sie in der 8er Version die Geschwindigkeit vom Host hatte, also 2,2 Sekunden.
Also nix mit lxc unter Proxmox 7, bei VMs wird dagegen die Hostpower der Kerne durchgereicht - schade eigentlich.
Ich hatte vor einer Weile auch solche Freezes mit ähnlichem Setup, 32 GB, Intel 8i5, meine Probleme waren mit PVE8 aber einem der ersten 6er Kernel aber mit verschiedenen.
Was letztendlich das Problem gelöst hat weiß ich nicht. Läuft jetzt stabil
Ich habe
- USB-HDD und SMB zum NAS(nicht immer Online) rausgenommen. Da waren mal Files offen und das hat Proxmox irgendwie nicht gemocht ohne was im Log aufzunehmen. Das war vermutlich bei mir das Problem
- Vollständig neu installiert ohne Backup oder clonen
- damals war auch einer der Kernel buggy
Ich war damals kurz vorm umsteigen. Es gibt keinen PVE Watchdog für Single Host sonst würde der Server wenigstens neu starten.
Linux Stresst den Rechner anders als Windows.
Zitat von: Damian am 20 Oktober 2023, 08:32:09Einen Hardwaredefekt würde ich eher ausschließen, der Rechner lief vorher drei Jahre lang unter Windows ohne Probleme. Zum Teil bleibt er schon kurz nach dem Booten stehen, da wird er noch nicht mal warm.
Um ggf. den Proxmox Kernel auszuschließen kannst ja mal Proxmox auf reinem Debian installieren. Ohne PVE Kernel werden manche Funktionen nicht laufen aber wenn dein Rechner schon nach dem Booten hängt könnte es der Kernel sein.
https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_11_Bullseye
Unter Debian kann man Proxmox zwar installieren. Aber es wird keine Virtualisierung laufen. War zu mindest bei mir so. Hatte vergessen in den Proxmox Kernel zu booten.
Aber nur so zum testen kann man es mal machen.
@Damian
Was für Speicherriegel hast Du da drin?
2 gleiche a 16GB?
Zitat von: CoolTux am 20 Oktober 2023, 10:18:46@Damian
Was für Speicherriegel hast Du da drin?
2 gleiche a 16GB?
ja, zwei mal die gleichen (identischen)
Zitat von: kadettilac89 am 20 Oktober 2023, 08:33:10Zitat von: Damian am 19 Oktober 2023, 17:46:52Proxmox 7er läuft bei mir seit Stunden stabil, die 8er blieb teilweise schon beim Booten hängen. Leider braucht die Schleife im debian lxc-Container fast 10 Sekunden, während sie in der 8er Version die Geschwindigkeit vom Host hatte, also 2,2 Sekunden.
Also nix mit lxc unter Proxmox 7, bei VMs wird dagegen die Hostpower der Kerne durchgereicht - schade eigentlich.
Ich hatte vor einer Weile auch solche Freezes mit ähnlichem Setup, 32 GB, Intel 8i5, meine Probleme waren mit PVE8 aber einem der ersten 6er Kernel aber mit verschiedenen.
Was letztendlich das Problem gelöst hat weiß ich nicht. Läuft jetzt stabil
Ich habe
- USB-HDD und SMB zum NAS(nicht immer Online) rausgenommen. Da waren mal Files offen und das hat Proxmox irgendwie nicht gemocht ohne was im Log aufzunehmen. Das war vermutlich bei mir das Problem
- Vollständig neu installiert ohne Backup oder clonen
- damals war auch einer der Kernel buggy
Ich war damals kurz vorm umsteigen. Es gibt keinen PVE Watchdog für Single Host sonst würde der Server wenigstens neu starten.
Ich habe auch schon alle USB-Platten abgehängt. Ich hatte ihm sogar verboten andere C-State einzunehmen, normalerweise hängt der im C08, was recht sparsam ist. Selbst als ich nur C01 erlaubt hatte (der Verbrauch war dann im Idle drei mal höher) ist der abgeschmiert.
Alleine die Tatsache, dass im Proxmox-Forum oft über "freezes" berichtet wird, ist kein gutes Zeichen für dieses System. Beim ESXi hatte z.B. ich keine Probleme. Ich könnte mir neue Hardware zulegen, ein AMD 5700U z.B. ist recht sparsam und hat die doppelte Power von dem intel-8259, aber irgendwie will ich das nicht einsehen, wegen Software gute und vor allem sparsame Hardware in Rente zu schicken.
Wenn das mit der Sata-SSD auch nicht klappt, werde ich einfach mal KVM unter debian ausprobieren. Ist zwar nicht so komfortabel wie Proxmox, aber hoffentlich stabiler.
Hab gerade mal meinen Thin Client Wyse N03D (https://www.parkytowers.me.uk/thin/wyse/3030/n03d.shtml) gemessen: 10 Sek.
Solche (lüfterlosen) Geräte gibt es immer wieder recht günstig in der Bucht.
Die verlinkte Seite ist übrigens eine tolle Quelle für die Suche nach weiteren geeigneten "Miniservern".
Zitat von: rudolfkoenig am 19 Oktober 2023, 16:56:23ZitatAMD Ryzen 9 5950X
Wie lange braucht die "dicke Kiste" fuer die Schleife (s.o)?
Bei welchem Verbrauch?
perl -e 'use Time::HiRes qw(time);my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'
2.18686199188232
ZitatIch habe auch schon alle USB-Platten abgehängt. Ich hatte ihm sogar verboten andere C-State einzunehmen, normalerweise hängt der im C08, was recht sparsam ist. Selbst als ich nur C01 erlaubt hatte (der Verbrauch war dann im Idle drei mal höher) ist der abgeschmiert.
Alleine die Tatsache, dass im Proxmox-Forum oft über "freezes" berichtet wird, ist kein gutes Zeichen für dieses System. Beim ESXi hatte z.B. ich keine Probleme. Ich könnte mir neue Hardware zulegen, ein AMD 5700U z.B. ist recht sparsam und hat die doppelte Power von dem intel-8259, aber irgendwie will ich das nicht einsehen, wegen Software gute und vor allem sparsame Hardware in Rente zu schicken.
Wenn das mit der Sata-SSD auch nicht klappt, werde ich einfach mal KVM unter debian ausprobieren. Ist zwar nicht so komfortabel wie Proxmox, aber hoffentlich stabiler.
Hier mal ein Zwischenstand zum freeze-Problem:
hiernach https://forum.proxmox.com/threads/proxmox-freeze-on-intel-nuc.68322/#post-598926
bin ich nicht allein mit dem Problem. Die Beschreibung passt sehr gut zu meinem Problem und ich habe schon lange die Vermutung, dass es mit den Stromspar-Modi etwas zu tun hat. Intel scheint bei den NUCs alles aus dem Chipsatz an Stromsparmaßnahmen herauszuholen, was geht. Das macht sich auch in dem sehr niedrigen Stromverbrauch im Idle positiv bemerkbar.
Nachdem auch die SATA-SSD bei mir nicht geholfen hat, habe ich nun angefangen die Stromsparmaßnahmen abzuschalten. Als erstes habe ich die Speedstep-Technologie abgeschaltet. Ich könnte mir vorstellen, das durch das Absenken der Frequenz und vor allem der Reduzierung der Spannung der CPU bei der Virtualisierung eine Instabilität entsteht. Erstaunlicherweise macht das Abschalten von Speedstep nicht viel aus, ich kann kaum einen erhöhten Strombedarf im Idle feststellen, das Gesamtsystem pendelt weiterhin um die 6 Watt.
So jetzt erst mal schauen, wie lange die Kiste durchhält. Es gibt noch zwei weitere Optionen im Bios, die ich ggf. noch ausprobieren kann, wenn es nicht die Lösung war. Allerdings kommt das Abstellen des Turbomodus für mich nicht in Frage. Man kauft sich ja nicht einen teuren Rechner, um ihn dann zu einem Billigteil zu degradieren, die Performance halbiert sich.
Ich werde weiter berichten, sobald ich neue Erkenntnisse habe.
Danke für das Update.
Ich weiß, das hilft dir nicht, aber ich möchte hier noch einmal feststellen, dass ich seit über einem Jahr - angefangen mit der damaligen Version von PVE - auf dem NUC7 und dem NUC11 Proxmox einsetze und bislang NICHT EINEN EINZIGEN Freeze oder Absturz oder Reboot oder oder hatte - weder mit 5er noch mit 6er Kernel.
Zitat von: Ralli am 25 Oktober 2023, 16:57:09Danke für das Update.
Ich weiß, das hilft dir nicht, aber ich möchte hier noch einmal feststellen, dass ich seit über einem Jahr - angefangen mit der damaligen Version von PVE - auf dem NUC7 und dem NUC11 Proxmox einsetze und bislang NICHT EINEN EINZIGEN Freeze oder Absturz oder Reboot oder oder hatte - weder mit 5er noch mit 6er Kernel.
ja, es gibt ja immer Streuungen bei den CPUs, es kann ja sein, dass meine z. B. beim Reduzieren der Spannung kritischer im Zusammenhang mit der Virtualisierung ist, als deine. Ich habe schon Posts gelesen, dass jemand seinen NUC zurückgeschickt hat und beim neuen keine Probleme hatte.
Ich denke, die meisten NUCs laufen nicht im Virtualisierungsmodus und da fallen solche Probleme nicht auf, denn mein Rechner lief zuvor jahrelang ohne Virtualisierung ohne einen einzigen Absturz.
Sorry wenn Du es schon gemacht hast: Ist das BIOS aktuell?
ich war gerade etwas überrascht:
Die Schleife liefert in einer Debian-VM auf einem DELL T30
perl -e 'use Time::HiRes qw(time);my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'
2.712406873703
Zitat von: Wernieman am 25 Oktober 2023, 20:16:57Sorry wenn Du es schon gemacht hast: Ist das BIOS aktuell?
ja, hatte ich schon geschrieben
übrigens das Abschalten von Speedstep reichte bei mir schon mal nicht - es hat zwei Stunden gehalten. Ich habe die nächste Spar-Option im BIOS deaktiviert.
Wie schon geschrieben, wenn das alles nichts hilft, werde ich KVM ausprobieren, wenn das dauerhaft stabil läuft, dann liegt es nicht nur an meinem Rechner.
Zitat von: pcbastler am 25 Oktober 2023, 21:15:11ich war gerade etwas überrascht:
Die Schleife liefert in einer Debian-VM auf einem DELL T30
perl -e 'use Time::HiRes qw(time);my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'
2.712406873703
Wieso? Das alte Schätzchen dürfte für diese Leistung schön Stromhungrig sein.
Zitat von: Damian am 25 Oktober 2023, 22:24:47Zitat von: Wernieman am 25 Oktober 2023, 20:16:57Sorry wenn Du es schon gemacht hast: Ist das BIOS aktuell?
ja, hatte ich schon geschrieben
übrigens das Abschalten von Speedstep reichte bei mir schon mal nicht - es hat zwei Stunden gehalten. Ich habe die nächste Spar-Option im BIOS deaktiviert.
Wie schon geschrieben, wenn das alles nichts hilft, werde ich KVM ausprobieren, wenn das dauerhaft stabil läuft, dann liegt es nicht nur an meinem Rechner.
Ich habe die letzte mögliche Option der Sparmodi deaktiviert mit der Konsequenz, dass der Rechner nicht mehr in den Turbomodus schalten kann, damit erreicht er bei der Performancemessung nur noch 3,5 Sekunden, also fast die halbe Leistung der möglichen. Ich lasse es jetzt so paar Tage laufen um sagen zu können, ob das System damit stabil ist oder nicht. Dass es für mich keine Option ist, habe ich schon geschrieben. Danach werde ich Proxmox von der Platte entfernen - zumindest auf diesem Rechner.
Eine Rückmeldung werde ich hier noch posten.
Zitat von: Damian am 26 Oktober 2023, 14:56:05Ich habe die letzte mögliche Option der Sparmodi deaktiviert mit der Konsequenz, dass der Rechner nicht mehr in den Turbomodus schalten kann, damit erreicht er bei der Performancemessung nur noch 3,5 Sekunden, also fast die halbe Leistung der möglichen. Ich lasse es jetzt so paar Tage laufen um sagen zu können, ob das System damit stabil ist oder nicht. Dass es für mich keine Option ist, habe ich schon geschrieben. Danach werde ich Proxmox von der Platte entfernen - zumindest auf diesem Rechner.
Eine Rückmeldung werde ich hier noch posten.
Update
Ich konnte in der Zwischenzeit neue Erkenntnisse sammeln. Ich denke es könnte für den einen oder anderen interessant sein.
Nachdem alle möglichen Optionen des BIOS keine Besserung brachten, habe ich zunächst Debian 12 installiert und darauf KVM. Es hat nicht lange gedauert - Absturz.
OK, dachte ich, vielleicht liegt es an Debian, da der gleiche Kernel verwendet wird wie bei Proxmox, also Ubuntu installiert, KVM brauchte ich schon nicht mehr installieren, denn auch da gleiches Verhalten. Also hat es vielleicht doch nichts mit Virtualisierung zu tun, war mein Gedanke.
Dann habe ich überlegt, was sich in der letzten Zeit an der Rechnerkonstellation geändert hat, schließlich lief er zuvor unter Windows lange Zeit ohne Probleme.
Der Rechner hatte von Anfang an einen 16 GB RAM-Riegel 2666 Mhz-Dual-Rank, dann habe ich ihm vor einem halben Jahr einen weiteren 16 GB RAM-Riegel 3200 Mhz-Single-Rank spendiert. Der Rechner selbst kann maximal 2400 Mhz. Diese Konstellation lief ein halbes Jahr ohne Problem.
Vor einem Monat brauchte ich für einen anderen Rechner einen 16 GB Riegel, also kaufte ich wieder den 16 GB 3200 Mhz-Single-Rank, um zukunftssicher zu sein. Dann dachte ich zwei gleiche Riegel in einem System wären besser als zwei verschiedene, also habe ich die beiden 3200 Mhz-Riegel in den NUC gesteckt und den 2666 Mhz in den anderen Rechner - das war wohl ein Fehler.
Offenbar verträgt der NUC8i5 die 3200 Mhz-Single-Rank Riegel nicht gut. In Kombination mit dem 2666 Mhz-Dual-Rank werden möglicherweise andere Einstellung vorgenommen, sodass der 3200 Mhz-Riegel keine Probleme macht - hat ja schließlich ein halbes Jahr unter Windows ohne Probleme funktioniert. Zumindest läuft Proxmox nun seit 16 Stunden ohne Zwischenfälle.
Sollte es doch noch einen Absturz geben, werde ich einen zweiten 16 GB 2666-Dual-Rank Riegel kaufen und hoffen, dass sich damit die Probleme erledigt haben.
Ein Memtest mit der alten Konfiguration hatte keinen Fehler produziert?
Zitat von: Wernieman am 29 Oktober 2023, 10:02:03Ein Memtest mit der alten Konfiguration hatte keinen Fehler produziert?
Nein. Ich denke, der hätte vermutlich nie Fehler gebracht, sondern der Rechner wäre eher abgestürzt, aber das machte er ja nach Tagesform mehr oder minder häufig.
Nun muss ich Proxmox in Schutz nehmen, wenn die Hardware stimmt, dann läuft alles.
Bisher keine Abstürze gehabt. Es sind einige VMs aktiv, sogar ein Proxmox Backup-Server (wegen inkrementeller Backups) als VM mit einer externen Platte - ist schon toll was man inzwischen alles zuhause laufen lassen kann, vor ein paar Jahren wäre das Home-Projekt alleine wegen der Stromkosten gescheitert.
Allerdings konnte ich heute einem Angebot nicht widerstehen und habe einen Minirechner mit doppelter Power (Ryzen 5560U) für knapp 200 Euro als zukünftigen Server erworben.
Freut mich, dass die Ursache gefunden wurde. Und nun wünsche ich dir viel Spaß mit deinem neuen Home-Lab :D .
Da auch ich in dieser Richtung ein Spielkind bin, habe ich mir zur Erweiterung meines Proxmox-Clusters mit HA noch einen refurbished HP EliteDesk G2 800 Mini Desktop i7-6700T gegönnt. Damit ersetze ich den RPi mit QDevice durch einen vollwertigen dritten Node. Haben ist besser als Brauchen 8) .
Nächstes Update zum Thema Hardware.
Ich habe nun auf dem neuen Mini (Ryzen 5560U) Proxmox installiert und die virtuellen Maschinen vom NUC (i5 8259U) per Server Backup herübergezogen - das hat funktioniert.
Einen kleinen Unterschied gibt es bei den C-States, während der Intel-Prozessor bis auf c10 herunter geht, ist beim AMD maximal c3 möglich, das macht sich etwas im Idle-Stromverbrauch bemerkbar.
Gemessen habe ich nur ein laufendes Proxmox ohne laufende VMs, also das absolute Minimum beim laufenden System (siehe Screenshot)
An die 3,27 Watt vom Intel-NUC muss ein Raspi mit einer Festplatte mit einem USB-Adapter erstmal herankommen :)
Beim AMD sind es dann 4,47 Watt, fairerweise muss man dazu sagen, steckt im AMD zusätzlich eine sata SSD drin, die allerdings im Idle kaum Energie verbraucht.
Etwas überrascht war ich allerdings von unserer Perl-Schleife, obwohl der AMD-5560U im Vergleich zum Intel-8259U lt. offizieller Benchmarks im Single Core fast 30 % mehr Performance bietet, läuft die Schleife mit ca. 2,2 Sekunden gleich schnell.
Dennoch werde ich den neuen Mini (AMD) zum Hauptserver machen, da er mit 6/12 Kernen insgesamt die doppelte Leistung des Intel-NUC mit 4/8 Kernen bietet und das bei 15 Watt TDP statt 28 Watt TDP beim NUC, was sich sicherlich unter Last bemerkbar machen würde.
Als nächstes werde ich die fhem-Installation vom raspi auf die neue VM-Maschine übertragen und danach den Raspi abschalten.
Mal schauen, was ich mit dem NUC nun mache, vermutlich lasse ich ihn als zweiten Proxmox-Server laufen, da kann er als Proxmox-Backupserver (als VM) weiter leben. Solange kein VM-Window-läuft tuckert er bei laufender Proxmox-Backupserver-VM auch nur mit 4,7 Watt.
Und wenn mir das noch zu viel an Stromverbrauch wird, dann kann man ihn per WOL-Script vor dem Backup wecken und danach wieder schlafen legen.
Wenn man bedenkt, dass man im Angebot für 213 Euro einen neuen Rechner mit der Power von 17! Raspis 4 als 6/12 Kernmaschine mit 16 GB und 500 GB SSD bekommt, die kaum mehr als ein Raspi an Strom verbraucht, dann erscheinen ca. 100 Euro für einen Raspi mit Netzteil, USB-SSD-Adapter und externer SSD mit einem Bruchteil der Performance als viel zu viel.
Daher kann ich die Aussage von Andreas Spiess bestätigen, wenn man etwas mehr machen will: "Besser als ein Raspi 5 ..."
Lasse den NUC als zweiten Node laufen und mache einen Cluster draus. So hast du eine einfache Redundanz. Für den Fall, dass der Spieltrieb stärker wird, nutze den RPi für ein QDevice und mache das ganze zu einer HA-Umgebung.
Ich habe meinen RPi mit QDevice jetzt aktuell ersetzt durch einen HP EliteDesk G2 800 i7 6700T und habe für ein paar Watt mehr nun einen "echten" dritten Node.
2.24843406677246 Sekunden.
Zitat von: Ralli am 04 November 2023, 15:33:56Lasse den NUC als zweiten Node laufen und mache einen Cluster draus. So hast du eine einfache Redundanz. Für den Fall, dass der Spieltrieb stärker wird, nutze den RPi für ein QDevice und mache das ganze zu einer HA-Umgebung.
Ich habe meinen RPi mit QDevice jetzt aktuell ersetzt durch einen HP EliteDesk G2 800 i7 6700T und habe für ein paar Watt mehr nun einen "echten" dritten Node.
2.24843406677246 Sekunden.
ja, das war auch meine Idee. Die Clusterkonfiguration muss ich mir noch anschauen, bisher hatte ich nur einen Node ;)
Gleichzeitig läuft ja auf dem NUC ja der Proxmox Backupserver als VM, somit habe ich schon mal eine physikalische Trennung der VMs und der Backups.
Jetzt muss ich nur noch, wie im Rechenzentrum, den Backupserver drei Etagen tiefer im Haus aufstellen, um eine räumliche Trennung zu haben :)
Was würde man zuhause nur ohne Home-Lab machen? :)
Update
Tja, was man inzwischen alles zuhause für kleines Geld als home lab laufen lassen kann.
Ich habe inzwischen auf einem Mini PC mit 14 Kernen sechs VMs laufen (FHEM, Windows, Home Assistant, Zigbee2Mqtt, Proxmox Backupsystem, Nextcloud, OMV).
48GB RAM, 6TB SSDs und 3TB HDD für Backups.
Braucht alles zusammen 18 Watt.
Auch die Performance kann sich sehen lassen:
perl -e 'use Time::HiRes qw(time);my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'
1.2419741153717
Ich warte noch auf den Tag, wo der erste unter eine Sekunde kommt ;D
Das ist eine interessante Zusammenfassung der Leistung die mich neugierig macht, könntest Du weitere Details (CPU, Speichertyp und bei der Ausstattung eine Zahl für kleines 'kleines Geld' angeben. Wie ist die Auslastung der VM, bei der angegebenen Leistung.
Es handelt sich um den NAB7 14/20 Kerne von Minis Forum (339 Euro als Barebone, Speicher, Platten usw. konnte ich übernehmen). Eigentlich ist es schon zu viel des Guten. Zuvor lief das System auf einem alten NUC 4/8 Kerne. In den VMs passiert nicht viel, daher pendelt die Auslastung des Systems um 1%. Die Schwuppdizität insb. bei Windows-VM per RDP ist etwas besser als zuvor, allerdings wird sie mit 18 Watt gegenüber 10 Watt bei 1% Last schon teuer als Dauerläufer erkauft. Der NUC hat auch nicht viel mehr als 1% Gesamtlast gehabt. Er war eigentlich gut genug, es war viel mehr der Reiz sich zu steigern und etwas neues auszuprobieren. Sollte allerdings das neue System richtig gefordert werden, würde sich der kleine auch 100 Watt gönnen, das passiert bei mir aber selten.
Wichtig war mir neben der nvme-Schnittstelle auch SATA für meine 4TB SSD, zwei Netzwerkkarten mit 2.5 GBit und die Nutzung von DDR4-Speicher, den ich übernehmen konnte.
Es ist inzwischen schon der vierte Mini, den ich besitze. Im Grunde habe ich das gesamte System mit allen VMs auf allen vier Minis bereits zufriedenstellend ausprobiert - das Umstecken der SSD mit allen VMs reichte schon - das System lief einfach weiter, egal ob Intel- oder AMD-Plattform. Einen Beelink mit dem N100-Prozessor nutze ich jetzt als zusätzlichen Backupserver, den ich automatisiert in den Standby schicke und für ein Backup wecke.
Meine beiden Raspis habe ich inzwischen in Rente geschickt. Wenn man einmal die Vorzüge der Virtualisierung kennengelernt hat, möchte man nicht mehr zurück.
Zitat von: Damian am 24 Juni 2024, 00:40:28Meine beiden Raspis habe ich inzwischen in Rente geschickt. Wenn man einmal die Vorzüge der Virtualisierung kennengelernt hat, möchte man nicht mehr zurück.
Dem kann ich nur beipflichten. Früher hatte ich nur einen Raspi auf dem FHEM lief und wenn ich was Neues testen wollte, hab ich extra vorher die SD-Karte gesichert.
Mit Proxomx erstellt man einfach einen neuen Container, testet darin - und man trennt HTTP-Server, FHEM usw einfach auf, statt alles auf einem System laufen zu lassen.
Rasperrys sind für mich nicht mehr interessant. Ich habe nur einen im Vergleich schwachen Mini-PC "Asus VivoPC / Mini-PC VC60-B013M". Ich habe ihn bisher nur mit Zoneminder und Gesichtserkennung in die Knie gezwungen - sonst keine Probleme. Im Screenshot meine Auslastung der letzten Woche (durchschnitt). BTW: auf dem Hostsystem läuft nicht nur Proxmox sondern auch Kodi.
Für mich kommt ein Raspi nicht mehr in Frage. Raspi höchstens wenn es wirklich nur FHEM können soll, sonst nix.
Ansonsten meiner Meinung nach immer einen Mini-PC, Virtuallisierung (Proxmox).
Ist jetzt fast Offtopic, aber vielleicht an dieser Stelle doch für den einen oder anderen interessant.
Nachdem ich meinen Server aufgerüstet habe und von dem Overkill-Server (14C/20T) begeistert war (besser haben als brauchen), hat mich der angestiegene Stromverbrauch (in der Grundlast von ca. 10 Watt auf 18 Watt) doch etwas enttäuscht. Daraufhin habe ich meine 24/7 Stromverbraucher noch mal genauer nachgemessen. Was gar nicht passte, war die Tatsache, dass meine Fritzbox 7590 AX sich 16 Watt gönnte, fast so viel wie der neue Server.
Heute wurde sie gegen eine 7530 AX ausgetauscht. Sie hat vergleichbare Features wie die 7590 AX, ist mit OS 7.81 genauso aktuell, hat Wireguard, hat sogar einen schnelleren Prozessor, was sich sofort bei der Bedienung der Fritzbox bemerkbar macht und kostet nur die Hälfe. WLAN ist genauso stabil (die theoretischen Übertragungsraten der 7590 AX wurden ohnehin nie erreicht) und jetzt kommts, sie braucht nicht mehr als 6 Watt, also 10 Watt weniger.
Nun stimmt wieder meine Gesamt-Strombilanz und das mit einem Höllen-Server ;D
Vielleicht könnt Ihr eine Kaufempfehlung abgeben. Ich würde gerne mit meinen Containern und VMs von der Synology auf einen Proxmox-Server umziehen. Bisher laufen in der Umgebung FHEM, Zigbee2MQTT, DeConz, Mosquitto usw. völlig problemlos und auch ausreichend performant. Falls aber mal eine Festplatte auf der DS ausfällt, dürfte das Wiederherstellen der Systeme recht aufwändig sein. Ich verspreche mir durch die Migration von Serverdiensten auf einen Proxmox-Server eine höhere Ausfallsicherheit und eine schnellere Wiederherstellung, falls es mal zu Problemen kommt.
Welchen Intel NUC würdet Ihr mir Stand heute empfehlen? Die schiere Menge an unterschiedlichen Konfigurationen erschlägt mich förmlich. Auf dem Gerät soll wie gesagt ausschließlich PVE laufen und dort dann virtualisiert FHEM, Zigbee, MQTT und alles, was zukünftig noch so an Services anfallen könnte. Gerne auch eine Windows-VM, die jedoch nur bei Bedarf laufen soll.
Mir wäre ein guter Kompromiss aus Leistung und Leistungsaufnahme wichtig. Gibt es Prozessoren, die sich besonders für Virtualisierungen anbieten?
Über ein, zwei Tipps würde ich mich sehr freuen.
LG
Oli
Wie man dem Thread hier entnehmen kann, experimentiere ich seit Oktober mit Proxmox. FHEM unter Proxmox ist bei mir seit über einem halben Jahr produktiv.
Ich habe Proxmox auf vier verschiedenen Mini PC getestet, hier eine kleine Zusammenfassung meiner Erfahrungen. Die vier Rechner sortiert nach CPU-Leistung und gleichzeitig nach Stromverbrauch:
-Ein Mini PC mit N100-CPU (4C/4T) (ca. 10 Watt Grundlast mit 7 VMs) (ca. 200 Euro 16GB/512GB) wird bei mir inzwischen als zweiter Proxmox-Backup-Server genutzt, hat zwei 2,5 Gbit Netzwerkkarten
-Ein alter NUC 8i5beh (4C/8T) (ca. 10 Watt Grundlast mit 7 VMs) (nur noch gebraucht zu kaufen) war mein vorletzter Produktiv-Rechner unter Proxmox, hat gut funktioniert
-Ein Mini PC mit AMD-5560U (6C/12T) (ca. 10 Watt Grundlast mit 7 VMs) (ca. 280 Euro 16GB/512GB) mein Preis/Leistung-Sieger, hat aber keinen 2,5 Gbit Netzwerkanschluss, wird z. Zt. als Schreibtischrechner unter Windows genutzt
-Ein Mini PC mit Intel 12700H (14C/20T) (ca. 500 Euro 32GB/1TB) (ca. 18 Watt Grundlast mit 7 VMs), hat entsprechend mehr Power und große Leistungsreserven, ist mein aktueller Produktiv-Rechner, hat zwei 2,5 Gbit Netzwerkanschlüsse, ist eigentlich schon ein Overkill für die 7 VMs
Performancevergleich der vier Rechner-CPUs:
https://www.cpubenchmark.net/compare/5157vs3299vs4883vs4721/Intel-N100-vs-Intel-i5-8259U-vs-AMD-Ryzen-5-5560U-vs-Intel-i7-12700H
Es laufen folgende VMs: FHEM, Nextcloud, Zigbee2mqtt, OMV, Proxmox-Backup-Server als VM, Windows 11, Home Assistent
Die Auslastung des Proxmox-Servers liegt im Normalbetrieb bei dem schnellsten Rechner (12700H) bei ca. 0,5%, beim langsamsten (N100) bei ca. 2%, die anderen liegen dazwischen.
Ich würde heute darauf achten, dass man den Server auf mindestens 32GB erweitern kann (am besten gleich mit 32GB kaufen), zwei interne Festplatten einbauen kann, und der Server einen 2,5 Gbit Netzwerkanschluss hat.
Alle Rechner haben für meinen Einsatzzweck (siehe VMs oben) genug Power gehabt, die "Schwuppdizität" ist beim stärksten natürlich am besten, wegen der starken Single-Core-Performance, sie wird aber teuer mit doppeltem Stromverbrauch erkauft. Die Leistungsreserven sind natürlich beim schwächsten N100 mit 4 Thread am geringsten, beim stärksten mit 20 Threads am größten.
Die Intel 12er-CPU-Reihe mit Performance- und Effizienz-Kernen läuft bei mir ohne jegliche Zwischenfälle (es gab anfangs Probleme unter Proxmox).
Original-NUCs sind aus der heutigen Sicht viel zu teuer, wenn man für die Hälfte gut funktionierende China Mini-PCs bekommt, die genauso sparsam sind und gleiche Performance bieten.
ZitatOriginal-NUCs sind aus der heutigen Sicht viel zu teuer ...
Und meines Wissens auch nicht mehr von Intel.
Noch ein Hinweis: Wenn Du Dich im 10W Bereich bewegst und der Server in einem normalen Raum sich befindet, würde ich auf Passive Kühlung achten.
Mein aktueller Rechner ist ein Zotac 340CI (gibt es nicht mehr), offiziell bis 8GByte Hauptspeicher, läuft hier aber mit 16GByte. Habe auch nur 1 SSD drin, mehr bedeutet mehr Stromverbrauch. Natürlich ist der Rechner "weg", wenn die SSD "weg" ist, aber dafür habe ich Backup (hoffentlich ;o) ). Habe zwar kein Proxmox, sondern Docker-Container am laufen, dafür läuft er mit 7W super. Würde bis heute in der Kategorie bleiben, eventuell wie m ein Vorredner schrieb, auf 32GByte wegen Zukunftssicherheit achten.
Hey, Ihr beiden!
Lieben Dank für die sehr ausführlichen Antworten.
Ich war jetzt kurz davor, mir auf Kleinanzeigen einen gebrauchten NUC i5/i7 für 200 - 250 Euro zu kaufen, bin dann aber aufgrund Damiens Hinweisen auf einen Beelink Mini S12 Pro mit N100, 16GB RAM und 512GB M2 SSD gestoßen. Den gab es bei Amazon für 189 Euro. Der hat zwar nur 1GB-LAN, aber ich denke, dass das für meine Anwendungen auch ausreichen wird. Ich plane nicht, große Datenmengen auf das Ding zu schieben. Das Gute ist, dass man bei den Preisen auch mal ein bisschen rumprobieren kann. Wenn ich dann feststelle, dass es irgendwo einen Flaschenhals gibt, dann probiere ich was anderes und habe nicht viel Geld in den Sand gesetzt.
Ich werde meine Synology als PVE-Backup Server einrichten. Eine M2 SSD habe ich auch noch ungenutzt im Schrank liegen. Falls die SSD im Proxmox-Server mal abrauchen sollte, sollte der Server mit neuer SSD und den Backups recht schnell wieder laufen.
Der PC kommt noch heute und freu mich schon darauf, FHEM, Zigbee, MQTT, Homebridge zu migrieren.
Ich werde später mal ein Feedback geben, wie es gelaufen ist.
LG
Oli
So, seit zwei Tagen läuft mein ganzes Geraffel (FHEM, MQTT, Devons, Z2M, Homebridge) stabil und flüssig auf dem kleinen Kästchen mit Proxmox. Es gab zwar den einen oder anderen Stolperstein, wie beispielsweise die ganzen Abhängigkeiten der Systeme untereinander wieder gerade zu ziehen, aber mittlerweile bin ich sehr zufrieden.
Obwohl meine Diskstation jetzt auch nicht sonderlich schwach auf der Brust ist, fühlt sich FHEM nun auch deutlich leichtfüßiger an. Auf der DS läuft jetzt nur noch eine VM mit einem PVE-Backup-Server. Einen kompletten Restore aller LXC und VM habe ich auch schon erfolgreich absolviert. Das Ganze hat inklusive Neuinstallation von PVE auf einer neuen SSD keine halbe Stunde in Anspruch genommen.
Was ich mich noch frage, ist, wieviel CPU-Kerne ich der FHEM-VM am besten zuweisen soll. Ich meine mal gelesen zu haben, dass FHEM nur einen Kern nutzen kann. Oder macht es aus irgendwelchen anderen Gründen Sinn, der VM mehr als einen Kern zuzuweisen?
LG
Oli
Hallo
Wieviel Watt gönnt sich der S12 Pro mit N100 denn so? Musstest du Feintuning am BIOS betreiben um den Verbrauch zu optimieren?
Gruß Ralf
Den Verbrauch habe ich ehrlich gesagt noch gar nicht gemessen. Werde ich aber am Wochenende mal machen.
Ich bin zwar einmal vor der Installation von PVE kurz durchs BIOS, hab mich aber im Einzelnen noch nicht mit Details beschäftigt.
LG
Oli
ZitatWas ich mich noch frage, ist, wieviel CPU-Kerne ich der FHEM-VM am besten zuweisen soll. Ich meine mal gelesen zu haben, dass FHEM nur einen Kern nutzen kann.
FHEM verwendet normalerweise einen Kern, es gibt aber Ausnahmen:
- manche Module laufen in einem separaten Prozess (Stichwort Blocking).
- um die SVGs zu berechnen startet FHEM auf Mehrkern-Rechnern weitere Prozesse. Die Anzahl der Prozesse haengt von Anzahl der Browser-Anfragen ab, typisch ist bis zu 5 weitere Prozesse.
Ich wuerde FHEM 6 Kerne zuweisen, und sie nicht exklusiv fuer FHEM reservieren.
Danke, Rudi.
Ich hab FHEM jetzt 4 Cores zugewiesen. Mit 6 startete FHEM nicht. PVE sagt "MAX 4 vcpus allowed".
Die Leistungsaufnahme schwankt in dieser Konfiguration zwischen 9 und 11 Watt.
LG
Oli
EDIT: Ja, kein Wunder! Die CPU hat ja auch nur 4 Kerne...
ZitatIch hab FHEM jetzt 4 Cores zugewiesen. Mit 6 startete FHEM nicht. PVE sagt "MAX 4 vcpus allowed".
Liegt vmtl daran, dass der N100 nur 4 Kerne hat.
>:(
Zitat von: rudolfkoenig am 04 August 2024, 08:16:34ZitatIch hab FHEM jetzt 4 Cores zugewiesen. Mit 6 startete FHEM nicht. PVE sagt "MAX 4 vcpus allowed".
Liegt vmtl daran, dass der N100 nur 4 Kerne hat.
Ich habe bei mir 2 Kerne für FHEM zugewiesen - das reicht bei mir alle Male aus. Ich nutze allerdings keine SVG-Plots.
Zitat von: RalfRog am 02 August 2024, 22:28:06Hallo
Wieviel Watt gönnt sich der S12 Pro mit N100 denn so? Musstest du Feintuning am BIOS betreiben um den Verbrauch zu optimieren?
Gruß Ralf
Ich nutze einen Beelink SER5PRO mit AMD Ryzen7 8C/16T, mit 1TB-NVME, 8TB-SATASSD, 4 USB-Dongles (1wire,ZWave,Homematic,CUL) zieht er sich im Idle 7w.
Über den Tag im Schnitt 0,22 kWh.
Es läuft 24/7:
FHEM LXC 2 Cores
DietPi-VM 4Cores
pihole LXC 1core
heimdalldashboard LXC 1core
nginxproxymanager LXC 1core.
BIOS oder ProxmoxHost noch ohne Poweroptimization
Hallo Ihr FHEM Profis,
darf ich hier bitte mal quer einsteigen.
Da ich drei produktive Raspberrys am laufen habe, überlege ich auch immer wieder, ob es nicht Sinn machen würde,
alles auf einen leistungsfähigen Mini-PC umzubauen.
Mein Grund warum ich es bisher nicht umgestalten kann, sind immer noch die GPIO-Ports. Für die onewire Temperatursensoren gibts dank den Shelly Addons ja mittlerweile gute Lösungen.
Ich habe aber immer noch mehrere 8 Kanal Relaisplatinen die auch 230 Volt Lastrelais steuern.
Ebenso sind auch noch mehrere potenialfreie 230 Volt Relais (auf GPIO Eingänge) zum erfassen von 230 Volt Außen- Bewegungsmelder in meinem Netz vorhanden.
Kennt jemand auch dafür Lösungen, um auf die empfindlichen GPIO Kanäle zu verzichten?
Hoffentlich "passt" meine Frage einigermaßen in diesen Thread.
Vielen Dank für Euer Profiwissen - das mir in den ca. 8 Jahren FHEM auch ohne eine Informatiker Ausbildung
immer wieder super Möglichkeiten eröffnet hat.
Viele Grüße und einen guten gesunden Start ins neue Jahr.
P.S. Überrascht bin ich, dass ein Mini-PC mit so wenig Stromverbrauch auskommen kann.
Ich würde dir Tasmota mit einem esp empfehlen. Damit kannst du 1-wire Temperaturen, Impulszähler, Stromzähler auslesen usw. oder Relais schalten. Kommunizieren kannst du per MQTT. Das funktioniert recht zuverlässig, ist preisgünstig, blockiert dein System nicht und lässt sich entfernt vom Server betreiben.
Zitat von: Damian am 29 Dezember 2024, 21:46:50Ich würde dir Tasmota mit einem esp empfehlen. Damit kannst du 1-wire Temperaturen, Impulszähler, Stromzähler auslesen usw. oder Relais schalten. Kommunizieren kannst du per MQTT. Das funktioniert recht zuverlässig, ist preisgünstig, blockiert dein System nicht und lässt sich entfernt vom Server betreiben.
Ergänzung dazu: Es gibt ESP32, die gleich ein LAN-Modul verbaut haben - dann allerdings weniger PINs direkt zur Verfügung stellen. Die könnte man aber auch mit i2c-Bausteinen aufrüsten (v.a. zum Schalten von Relays etc.). Relativ günstig und neuerdings mit eigenem Treiber für Tasmota z.B.: https://tasmota.github.io/docs/MCP230xx/
(Tasmota könnte dann z.B. einen Teil der Relays auch direkt als Rollladenaktor verwenden...)
Oder du wechselst das Pferd und setzt (für die Outputs) sowas ein (würde immer die ZigBee-Version nehmen!): https://de.aliexpress.com/item/1005007273195157.html?spm=a2g0o.productlist.main.47.6e232c95AdhT0A&algo_pvid=611c0bd8-4ae7-490b-8169-2e867d1d5646&algo_exp_id=611c0bd8-4ae7-490b-8169-2e867d1d5646-23&pdp_npi=4%40dis%21EUR%2194.29%2146.19%21%21%21701.04%21343.45%21%40211b615317355389557706519ef317%2112000040023983551%21sea%21DE%212808040319%21X&curPageLogUid=AVawet3JGeQ2&utparam-url=scene%3Asearch%7Cquery_from%3A (Tuya 24 Kanal Smart Wifi/ZigBee Wireless Relais Switch Modul App RF Fernbedienung Smart Home Automation Modul 12V, https://zigbee.blakadder.com/Tuya_TY16-V7030.html)