Neue Hardware reif: Raspberry Pi 2 (Quadcore) für 35$ vorgestellt

Begonnen von Garagenhaus, 02 Februar 2015, 09:41:56

Vorheriges Thema - Nächstes Thema

kpwg

Zitat von: juppzupp am 10 Februar 2015, 19:15:12
Wenn man wollte (ich nicht!) könnte man das per taskset beim Aufruf des Programms steuern,oder innerhalb perl mit :
use Sys::CPUAffinity;

Warum nicht? Ist doch schade um die drei nicht genutzten Kerne. Habe gerade einen Monatsplot geschaut: der erste Kern zeigt 100%, der Rest langweilt sich.

juppzupp

Zitat von: kpwg am 11 Februar 2015, 19:15:26
Warum nicht? Ist doch schade um die drei nicht genutzten Kerne. Habe gerade einen Motatsplot geschaut: der erste Kern zeigt 100%, der Rest langweilt sich.
Konkreter: Ich würde nicht mehrere Fhem Instanzen auf unterschiedlichen Cores laufen lassen um die dann via fhem2fhem wieder zusammenzufassen.
Das wäre mir ein zu wackeliges Konstrukt, nicht troubleshootbar, etc.
Speziell beim raspi sitzt das Nadelöhr doch noch immer auf dem USB bus, der SD und dem damit verbundenem hohen wa anteil. Da nutzen die cores auch nix.
Ist aber nur (m)eine Meinung.

kpwg

Bin mir nicht mehr so ganz sicher, ob die SD Karte immer der "Bremser" ist, wenn ich mit htop schaue und fhem belaste. Der erste Kern steht dann bei 100%.

juppzupp

Wieviel Prozent davon sind wa?
Leg ne ramdisk an, und Vergleich wie lange das plotten dann bei welcher load dauert.

chris1284

meinst du die cpu-last würde auf 100 gehen wenn die gewchwindigkeit der sd das problem wäre? wenn die daten zu langsam kommen würden gäbe es doch keinen grund das die cpu zu 100% ausgelastet ist, würd in dem fall ehr davon ausgehen das sie sich lanweilt weil nichts nach kommt

AHA1805

AHA 1805 RIP 29.08.2016 --> RUHE IN FRIEDEN
In Gedanken Bei dir HANNES
Dein Bruder Gerd (Inputsammler) Vermisst dich Hannes (AHA1805)

hexenmeister

Zitat von: chris1284 am 12 Februar 2015, 06:26:41
meinst du die cpu-last würde auf 100 gehen wenn die gewchwindigkeit der sd das problem wäre?[...]
Das kommt drauf an... Ich weiß nicht, on Raspberry so etwas wie DMA hat, es wäre also theoretisch schon denkbar, dass die Auslastung daher kommt, dass CPU  mit dem Schaufeln von Daten bzw. mit dem (aktiven) Warten drauf beschäftigt ist. SOllte zugegebenermaßen bei heutigen  Systemen nicht mehr der Fall sein ;)

juppzupp

Zitat von: hexenmeister am 12 Februar 2015, 07:03:55
Das kommt drauf an... Ich weiß nicht, on Raspberry so etwas wie DMA hat, es wäre also theoretisch schon denkbar, dass die Auslastung daher kommt, dass CPU  mit dem Schaufeln von Daten bzw. mit dem (aktiven) Warten drauf beschäftigt ist. SOllte zugegebenermaßen bei heutigen  Systemen nicht mehr der Fall sein ;)
Das hat mit heute oder gestern nicht viel zu tun. Das broadcom soc wurde ursprünglich für den mobile makrt entwickelt. Kann man einfach nicht mit ner x86 desktop Architektur vergleichen.
Zitat von: chris1284 am 12 Februar 2015, 06:26:41
meinst du die cpu-last würde auf 100 gehen wenn die gewchwindigkeit der sd das problem wäre? wenn die daten zu langsam kommen würden gäbe es doch keinen grund das die cpu zu 100% ausgelastet ist, würd in dem fall ehr davon ausgehen das sie sich lanweilt weil nichts nach kommt
Mein ich nicht, weiss ich. Also das die CPU last hoch geht wenn die SD nicht nachkommt. Der Grund dafür ist der mmcqd, der die CPU hoggt.
Obs im o.g. Fall der Grund ist, kann man nicht sagen, da zu viele infos fehlen. Wie man es rausfinden könnte hab ich ja beschrieben.

hexenmeister

Zitat von: juppzupp am 12 Februar 2015, 10:50:46
Das hat mit heute oder gestern nicht viel zu tun. Das broadcom soc wurde ursprünglich für den mobile makrt entwickelt. Kann man einfach nicht mit ner x86 desktop Architektur vergleichen.
Wenn ich von 'heute' spreche, meine ich bestimmt nicht x86. ;)


juppzupp

deswegen referierst du 'heute'  über den supermodernen DMA ?

Zitat von: hexenmeister am 12 Februar 2015, 13:13:37
Wenn ich von 'heute' spreche, meine ich bestimmt nicht x86. ;)



hexenmeister

Zitat von: juppzupp am 12 Februar 2015, 17:56:50
deswegen referierst du 'heute'  über den supermodernen DMA ?
Wenn man genau liest, sieht man, dass die Rede nicht um "DMA", sondern um "so etwas wie DMA" war. ;)
Insofern war hier DMA nur ein Beispiel, ein Platzhalter für alle Techniken, Speichertransfer ohne Beteiligung von CPU zu bewerkstelligen.
Und nein, ich weiß immer noch nicht, ob Raspberry so eine Technik (ich vermeide mal das Wort DMA ;) ) hat und wie sie ggf. genannt wird. ;)

juppzupp

Der rpi hat 16 DMA Kanäle. Aber das hilft nicht da wir über mmcqd den Flaschenhals an die CPU weitergeben.

Banana_Joe

ich hab mir den raspi 2 nun auch gegönnt, mal gespannt was das teil abseits vom datenblatt so in der praxis ausmacht.

Bei Pollin übrigens wieder lieferbar.

volschin

Heute wurde übrigens gleich mal ein neuer Kernel nachgeliefert:
3.18.7-v7+ #755 SMP PREEMPT Thu Feb 12 17:20:48 GMT 2015

Ich hoffe, dass sich meine Instabilitäten damit erledigen. Aber ich bin ja anscheinend der einzige in der Runde hier, der damit Problemchen hat.
Intel NUC+Ubuntu 24.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7690, Echo Dots+Show8, HomeBridge

volschin

Die Auswirkungen des neuen Kernels bei mir sind interessant. Vorher stand mir ein Total memory von 744 MB RAM zur Verfügung, danach 927 MB.
Die Ausgaben bzgl. loadavg haben sich ebenfalls verändert. Während die 5 Minutenkurve vorher im Schnitt deutlich über der 15 Minutenkurve lag, liegt sie jetzt deutlich darunter. Statistisch gesehen, sollen sich die Abweichungen eigentlich eher egalisieren. Insofern ist hier sowohl vorher als auch nachher nicht alles gut.
Intel NUC+Ubuntu 24.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7690, Echo Dots+Show8, HomeBridge