habe ihn seit 3 Tagen im Betrieb. Er läuft 1a:thumbs1:
Raspberry 2 erscheint
-
Burnz84 -
2. Februar 2015 um 10:16 -
Erledigt
L
I
V
E
Stammtisch ab 20:30 Uhr im Chat
-
-
Raspberry 2 erscheint? Schau mal ob du hier fündig wirst!
-
[quote='meigrafd','http://test.forum-raspberrypi.de/forum/index.ph…2387#post132387']
bah die Schweine von Pollin haben zwar im Shop die ganze zeit "Verfügbar" stehen, aber die haben erst heute ne neue Lieferung gekriegt und schicken den Pi2 erst am Montag raus *kotz*
..natürlich hab ich ihn mit Sofortüberweiung bestellt... =(Bitte bleibt sachlich. Es fehlt uns immer die interne Information!
Schwiene gehört hier nicht hin. -
Ich habe bei Pollin bestellt, zwei Tage danach war der Raspberry bei mir.
Es kann sein, dass es sich etwas wegen der höhen Nachfrage verzögert!
Grüße -
Bitte bleibt sachlich. Es fehlt uns immer die interne Information!
Schwiene gehört hier nicht hin."Schweine" ist noch ein netter Ausdruck...
Laut Gesetzgebung ist es Betrug mehrere Tage vorzugeben eine Ware im Onlineshop auf Lager und "Versandfertig in 1-2 Tagen" zu haben was aber nicht der Realität entspricht.
Komisch ist auch das erst gestern, wo meiner nun endlich angeblich verschickt wurde, der Status im Shop geändert wurde..Das sind Geschäftspraktiken die nicht gerade schön sind - weil es natürlich ein riesen Geschäft ist weil die Nachfrage enorm ist... Wer möchte sich das nicht entgehen lassen...
Also wie möchtest Du wie ich das stattdessen nenne?
Zudem spricht nichts dagegen andere hier darüber zu informieren das es bei Pollin Lieferschwierigkeiten gibt, da hier zuvor auch gepostet wurde dass sie dort bestellt haben...
Und wenn man meinen Post im Kontext betrachtet, hatte Jörg zuvor geschrieben das er sie auf Lager hat - woraufhin ich dann frustriert angedeutet habe dass ich lieber bei ihm hätte bestellen sollen um den Pi2 jetzt bereits zu besitzen.
Also imho gehört Dein Post hier nicht her - zumal der meine von letzter Woche Freitag ist, deiner aber erst von heute
-
Hallo zusammen,
eigentlich wollte ich mich in diesem Thread nicht beteiligen.
Aber es geht hier um die Aufteilung von Marktanteilen. Jeder Händler, der vorgibt, Pi2 im Lager zu haben, bekommt Bestellungen ohne Ende... Hat er wirklich welche auf Lager, wird er diese auch in Nullkommanix los.
Auf Bestelleingänge warten und dann erst selber bestellen! Das hält die Lagerbestände und Lagerkosten niedrig - und mindert das Geschäftsrisiko!
Ich hatte hier Anfang Januar einen Thread aufgemacht über RPi B+ bei Omega in Freiburg. Die haben die Teile damals (und immer noch) für 29 € vertrieben. Und die haben eine Unmenge inkl. Zubehör auf Lager!
Ist doch bei der Börse genauso. Man kann Aktien bei einem Händler kaufen, der die Aktie noch gar nicht besitzt. Das Geld fließt und kurbelt die Wirtschaft an. Und der Rest ist Datenabgleich zwischen irgendwelchen Computern.
Ich finde die Praxis auch nicht gut, dass hier irgendwelche Materialflüsse vorgetäuscht werden, aber letztlich spielen wir als Konsumenten nur in der Masse eine Rolle. Dem Händler (ohne Ware) ist der Einzelbesteller vergleichsweise unwichtig. Dem geht es nur um Cash-as-cash-can.
Ich zahle lieber ein paar Euro mehr, um bei einem Händler meines Vertrauens die vorhandene Ware zu erhalten - anstelle irgendwelche Spekulationsgeschäfte ohne Risiko zu fördern.
Beste Grüße
Andreas
-
Habe meinen Pi2 bei Pollin am 3.02. bestellt, am 4.02. kam die Versandbestätigung und am 5.02. kam er bei mir mit allen bestellten Teilen an.
Aber ich hätte mich an meigrafd Stelle genauso geärgert ...Dann sollten die wenigsten "noch X Stück verfügbar" oder so schreiben ... und falls er 30 Sekunden später nicht mehr verfügbar ist halt nachfragen ob man trotzdem bestellen will ...
Ansonsten gibt es ja auch ein Rückgaberecht bei inkorrekt Verhalten (äh nicht gefallen, zu spät geliefert oder so)! -
Gestern kam meiner an.
Jörg hat wirklich schnell verschicktLäuft wie die Sau ( Raspbian).
Scheint aber etwas mehr Strom zu benötigen.
Mit dem Netzweil wo ich bisher meine B betrieben habe ( 1A ) und nur einem USB Keboard ging er in einen Boot-Loop.
Ein Netzteil mit 1.5A brachte den gewünschten Erfolg.Nach kurzem spielen mit dem Devicetree ( die alten B laufen noch mit einem uralt Kernel ) lief auch der W1 Bus ohne Probleme.
Mal schauen was ich jetzt mit dem mache. -
Spoiler anzeigen
So, ich hab nun auch endlich meinen Pi2 gekriegt - will hier jetzt aber gar nicht weiter drauf eingehen das ich nie wieder bei Pollin bestellen werde (was schief gehen konnte is eingetreten) ...
Erster Eindruck vom Pi2 ist sehr gut.
2015-01-31-raspbian.img auf eine neue microSD geflasht und der Pi2 bootet sofort und schön schnell.Allerdings ist mir nun aufgefallen dass das raspi-config einen kleinen Fehler beinhaltet, und zwar wenn man den " Device Tree " enabled. Laut Script soll in /boot/config.txt dann die Option device_tree= einkommentiert werden oder wenn nicht vorhanden, diese Zeile einzutragen. Eine solche Einstellung gibt es in meiner /boot/config.txt aber nicht, auch nicht nach wiederholtem raspi-config Aufruf und genauem achten auf " Device Tree is enabled "
Derzeit scheint es aber über apt-get keine neuere Version zu geben...
Also, den Befehl den eigentlich raspi-config ausführen sollte, manuell ausgeführt und kontrolliert:
Coderoot@raspberrypi:~# printf "device_tree=\n" >> /boot/config.txt root@raspberrypi:~# grep tre /boot/config.txt device_tree= root@raspberrypi:~#
Wiederhole ich dieses Spiel aber auch mit den SPI und I2C Sachen, tritt das selbe Phänomen auf :s
Bei SPI tritt auch eine Fehlermeldung auf:Nunja... Erstmal egal, ich muss ja nicht alles verstehen
Weitere mit der Analyse.
Wie einige schon festgestellt haben werden die Cores des Pi2's standardmäßig mit nur 600MHz getaktet. Warum das so ist konnte ich bisher nicht ergründen - dabei heißt es offiziell ja er würde mit 900MHz ausgeliefert werden... Ich vermute mal dass das noch genau so wie der RAM eine Standard Einstellung im Kernel ist.
Auch wenn man "arm_freq=900" in der config.txt einstellt ändert sich daran solange nicht bis er ausgelastet wird - was ja auch schon bei den Vorgängern so war. Erst "force_turbo=1" setzt die Frequenz permanent auf den angegebenen Wert.Wegen des RAMs habe ich in Beitrag#15 ja bereits recherchiert das dieser durch den Standard Kernel auf ~750MB begrenzt wird, weil noch Programme wie SonicPI mit so viel RAM nicht laufen...
Auf dem oben erwähnten Image ist folgender Kernel vorinstalliert:
Nach einem rpi-update und reboot hat man dann auch vollen Zugriff auf den RAM, abzüglich der Standard 64MB für die GPU also
Code3.18.6-v7+ #754 SMP PREEMPT Sun Feb 8 20:34:22 GMT 2015 armv7l GNU/Linux root@raspberrypi:~# grep ^MemTotal /proc/meminfo MemTotal: 949364 kB root@raspberrypi:~#
(auch mit dem neuen Kernel ändert sich am Verhalten von raspi-config nichts)
Übrigens habe ich bis zu diesem Zeitpunkt weder "apt-get upgrade" noch irgend etwas anderes manuell mit apt-get gemacht.
Der Standard CPU Takt von 600MHz besteht mit dem bis dato aktuellen Kernel leider weiterhin... Das finde ich wie erwähnt etwas seltsam, wieso die Foundation dann von Standard 900MHz spricht
Die Standard Konfiguration, die laut vcgencmd get_config int angeblich aktiv sein soll, sieht wie folgt aus:
Code
Alles anzeigenarm_freq=900 sdram_freq=450 over_voltage_avs=0x1b774 disable_l2cache=1 program_serial_random=1 config_hdmi_boost=2 emmc_pll_core=1 hdmi_force_cec_address=65535 ignore_lcd=1 framebuffer_ignore_alpha=1 framebuffer_swap=1 arm_control=0xa5800010 temp_limit=85 force_pwm_open=1 pause_burst_frames=1 avoid_fix_ts=1
(in meiner config.txt steht bisher nur gpu_mem und device_tree drin)
Da kann ich die SoC / RAM relevanten Sachen nicht ganz nachvollziehen, aber vermutlich liegt das daran das ich noch kein "force_turbo=1" an hab
Da ich den PI nackt auf dem Tisch liegen habe, liegt die Temperatur der SoC bei ca. 39 - 40 °C (bei angenehmen 23°C Zimmertemperatur). Der RAM Chip wird dabei kaum merkbar warm also bei weitem nicht spürbar warm wie die SoC - obwohl der PI wie gesagt flach auf dem Tisch liegt und da unten nichts zirkuliert
Man kann nebenbei erwähnt das System auch "on the fly" übertakten, über folgenden einen einfachen Trick (bezieht sich nicht nur auf den Pi2)
Spoiler anzeigen
Code
Alles anzeigenroot@raspberrypi:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 600000 root@raspberrypi:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 600000 root@raspberrypi:~# echo 700000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq root@raspberrypi:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 900000 root@raspberrypi:~# /opt/vc/bin/vcgencmd measure_clock arm frequency(45)=900000000 root@raspberrypi:~# root@raspberrypi:~# echo 600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq root@raspberrypi:~# /opt/vc/bin/vcgencmd measure_clock arm frequency(45)=600000000 root@raspberrypi:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor ondemand root@raspberrypi:~# echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor root@raspberrypi:~# /opt/vc/bin/vcgencmd measure_clock arm frequency(45)=900000000 root@raspberrypi:~#
Aber nach einem Reboot ist das natürlich wieder weg..
https://wiki.archlinux.org/index.php/CPU_…aling_governors
http://raspberrypi.stackexchange.com/questions/8877…ia-command-lineNach übertakten über den im Spoiler erwähnten Weg, steigt die Temperatur auf ca. 41 - 42°C... Aber mein PI hat derzeit auch nix zu tun
Also nun weiter mit SoC Taktung auf 900MHz, da das ja eigentlich normal sein sollte für den Pi2.
Da ich ein starker Verfächter von X11-forwarding bin, war ich äußerst(!!!) überrascht wie verdammt schnell LXDE gestartet wird. Wahnsinn!!
Keine 5 Sekunden hats gedauert dann war LXDE bedienbar Dabei ist die Auslastung im Vergleich zum alten Pi wirklich ein Witz, die 3.Core wird gerade mal mit 5% ausgelastet alle anderen langweilen sich. RAM Auslastung liegt bei ca. 47 von 927MB, kann man also auch ignorierenDie GPU hat bei mir wie erwähnt 64MB zugewiesen, mit LXDE auf sind aber davon noch ca. 43MB frei. (ich hab aber nur LXDE auf, keine Programme). Da aber die GPU auch den ganzen Kernel usw in seinen Speicher läd, kann die GPU von den zugewiesenen 64MB effektiv nur 44MB nutzen - also verbraucht LXDE aktuell nur 1MB GRAM
Stellt man gpu_ram in /boot/config.txt auf 16MB runter, kann die GPU davon effektiv 10MB nutzen aber LXDE lässt sich dann nicht mehr starten... Stellt man gpu_ram auf 32MB, sind nach Reboot effektiv 12MB nutzbar und LXDE lässt sich weiterhin nicht starten
Wer also LXDE benutzen können will muss das weiterhin auf mind. das voreingestellte von 64MB lassen. Da hat sich also zum Vorgänger nichts verändert.
Mehr kann aber nie schaden, schließlich hat man jetzt auch doppelt so viel zur Verfügung und kann protzen statt kleckernSo als letzter Test den ich jetzt noch mache bevor ich mich an mein eigentliches Vorhaben setze, wäre eine gnadenlose Übertaktung und stresstest
1. Versuch:
Codeforce_turbo=1 temp_limit=68 arm_freq=1000 core_freq=275 h264_freq=275 isp_freq=275 v3d_freq=275 sdram_freq=500 over_voltage=6
Keine Probleme, schön schnell gebooten, Einstellungen sind aktiv.
Temperatur steigt ganz langsam an und pendelt sich im Idle bei ca. 44° ein.
LXDE startet geführt nicht wirklich schneller da es zuvor auch schon verdammt stell startete.Jetzt starte ich mal ein stresstest: nice yes >/dev/null &
Beim starten des Befehls wird erst nur die erste Core auf 100% ausgelastet, nach 10 Sekunden wechselt das aber auf die 2.Core und bleibt da.
Temperatur steigt auf 48 - 49 °C. Gefühlt wird nun auch der RAM Chip etwas wärmer aber imho kann man das weiterhin ignorieren.
Führ ich den 'nice' Befehl nun noch mal aus, wird auch ein weiterer Core belastet.
Temperatur steigt nun auf 55 - 56 °C an.
LXDE lässt sich davon nicht beeindrucken, alle Bedienfelder lassen sich so bedienen als gäbs keine Auslastung :thumbs1:
Also noch ein 'nice' .. irgendwann muss der doch auch mal aufgeben
Wenn 3 Cores zu 100% ausgelastet werden lässt sich LXDE noch immer so bedienen als würds ihn nicht interessieren. Der Webbrowser 'NetSurf' startet auch noch angenehm schnell. Also muss noch ein 'nice' her!
4 Cores auf 100% ausgelastet, CPU Temperatur liegt nun bei 65 - 66°C. LXDE ist ein kleines bisschen langsamer, aber auch bei weitem nicht so wie noch zu Pi-1 Zeiten. Hm, wieso krieg ich den nicht in die Knie :s Geh tot du sau!!Also alle 4 Cores auf 100% Auslastung bei einer überwiegenden ARM-Übertaktung auf 1GHz und die CPU-Temperatur liegt nun bei 67°C (Zimmertemperatur: 23,6°C)... Zigarettenpause gemacht (6min) Temperatur unverändert. :thumbs1:
So, genug Stresstests - bevor ich mich nun an mein eigentliches Vorhaben setze, sei noch erwähnt das obige Einstellungen aber auf " arm_freq=1100 " auch noch wunderbar funktioniert Nur 1,2GHz mag er dann doch nicht mehr, da müsste man ggf noch mehr verstellen aber das probier ich später vielleicht mal
-
Tja, hättest mal bei mir bestellt!
Mit dem device tree solltest Dich nochmal beschäftigen. Wählst Du mit raspi-config "device tree enabled" passiert erst mal gar nichts, weil ohne den EintragDT aktiviert ist. Da wird auch nichts auskommentiert. Erst nachdem Du "device tree disabled" gewählt hast wird der Eintarg
gemacht. Danach wird er auskommentiert, wenn Du DT per raspi-config wieder aktivierst.
Den Rest wirst Du auch noch begreifen, zumal die Option DT zu deaktivieren, nur ein Übergang sein wird. Das wird wegfallen und es wird nur noch DT geben. Ich bin gerade dabei alle meine Anleitungen auf DT umzuarbeiten. -
Was ist DT? Und wieso hat es Einfluss auf deine Anleitungen.
Frage erübrigt sich:
-
Also alle 4 Cores auf 100% Auslastung bei einer überwiegenden ARM-Übertaktung auf 1GHz und die CPU-Temperatur liegt nun bei 67°C (Zimmertemperatur: 23,6°C)... Zigarettenpause gemacht (6min) Temperatur unverändert. :thumbs1:
Hallo Meigrafd,
konntest Du nach o.g. Zigarettenpause auch mal die Temperatur vom RAM-Baustein prüfen? -
Bezüglich der 600 MHz haben wir an anderer Stelle herausgefunden, dass das wie bei den alten Pis der Idle Speed ist.
Wenn man bei den alten Pis 1000 MHz eingestellt hat, zeigte er trotzdem nur 700 MHz an, da er den eingetragenen Sollwert erst bei Bedarf einstellt.
Wo ich Dir recht gebe, ist die Angabe von 900 MHz als Standardtakt. Aber es ist halt wie in der normalen CPU Welt. Fast überall werden die Turbofrequenzen angegeben und im Normalmodus sind die Gurken viel langsamer. Das fiel mir schon damals bei meinem Intel C2Q mit 2,6 GHz auf. Wurde mit 2,6 GHz (von Intel) angegeben und verkauft und wenn man dann im Windows den Speed abgefragt hat, waren es "nur" 2,0 GHz.
Zum Glück geht man dort jetzt immer mehr dazu über, dass man auch "Turbo" hinschreibt und auch die normale Frequenz nennt.
Leider geht da die Org wohl andere Wege.
Ich hatte mir das auch schon fast gedacht, da man nun 4 Cores in den Chip gepackt hat und es in Murphys Welt normal so ist, dass Mehrkernprozzis immer niedriger getaktet sind als die Wenigerkerner, zumindest eine Weile.
Aber trotz alle dem bin ich begeistert, das kleine Teilchen macht auch mit 600 MHz eine gute Figur. Ob das mit den 900 MHz automatisch passiert (wäre eine Neuerung ggü. den alten Pis) oder man das wieder in der Config.txt eintragen muss, habe ich noch nicht getestet. Würde es bei Bedarf automatisch passieren, wäre das auch wiederum nicht ganz so schlimm als wenn er permanent auf 600 MHz rumgeigt, denn bei Letzterem hätten die Anfänger und reinen Nutzer wohl nicht das volle Potential.
-
konntest Du nach o.g. Zigarettenpause auch mal die Temperatur vom RAM-Baustein prüfen?
Das kann man leider nicht auslesen. Aber gefühlt war das nicht erwähnenswert Hab ich nur ganz leicht gemerkt das der warm war, wohingegen der SoC sich schon nach "ich verbrenn mich gleich" angefühlt hat. Also schon ein krasser Unterschied
Bezüglich der 600 MHz haben wir an anderer Stelle herausgefunden, dass das wie bei den alten Pis der Idle Speed ist.Ja das ist schon klar. Das hängt ja mit "force_turbo" bzw "governor" zusammen - wie ich auch beschrieben habe.
Allerdings ist beim alten Pi-1 die Idle-Speed 700MHz und mit dieser Tatktung wird er auch verkauft. Der Pi2 hingegen wird als 900MHz SoC verkauft, läuft aber im Idle nur mit 600MHz ? Das kritisierte ich halt...
Fast überall werden die Turbofrequenzen angegeben
Ne, Normal ist das nicht. Allgemein erwähnt wird Turbo natürlich, klar. Aber es wird nicht so getan als wäre "Turbo" die Standard Taktung.
Beim Pi2 ist der Turbo zudem 1,1GHz also auch etwas völlig anderes als die "Standard Taktung".Ich hatte mir das auch schon fast gedacht, da man nun 4 Cores in den Chip gepackt hat und es in Murphys Welt normal so ist, dass Mehrkernprozzis immer niedriger getaktet sind als die Wenigerkerner, zumindest eine Weile.
Entschuldige aber dieser Vergleich ist Quatsch.
Ich hatte auch schon etliche Multicore CPUs - Jeder davon lief auf den vom Hersteller angegebenen Standardtakt. Stand zB 3 GHz drauf lief der ohne Zutun auch auf 3 GHz. Untertakten tut zudem auch kein Hersteller. Und wenns einen Werksseitigen Turbo gab kam der erst zum Einsatz wenn der CPU ausgelastet wurde etc.Beim Pi2 steht 900MHz drauf, er läuft ohne Zutun aber nur auf 600MHz.
-
Beim Pi2 steht 900MHz drauf, er läuft ohne Zutun aber nur auf 600MHz.
Der Pi2 läuft mit 900MHz. Leider wurde vergessen, das in der /boot/config.txt zu ändern. Da steht noch der Wert vom Model B drin. Beim neuen Image ist das bei Raspbian behoben, also der Eintrag geändert.Prüf das mal bitte jemand, damit da noch ne zweite Meinung mit dazu kommt. Kann auch sein, dass ich das selbst umgestellt hatte, bei dem ausprobieren der Funktionen des device tree.
-
Der Pi2 läuft mit 900MHz. Leider wurde vergessen, das in der /boot/config.txt zu ändern. Da steht noch der Wert vom Model B drin. Beim neuen Image ist das bei Raspbian behoben, also der Eintrag geändert.Es geht darum, das man beim alten Pi keinen solchen Eintrag haben muss damit er mit seinem Standardtakt läuft! Bzw der Mindesttakt auch nicht niedriger is
Lösch alles in /boot/config.txt und reboote, dann fährst du mit der Standardtaktung, der ab Werk Taktung. Beim alten Pi ist das 700MHz, beim neuen aber 600MHz!
Pi-1-B:
Spoiler anzeigen
Code
Alles anzeigenroot@RoPi:~# uname -a Linux RoPi 3.18.6+ #754 PREEMPT Sun Feb 8 20:22:45 GMT 2015 armv6l root@RoPi:~# cat /boot/config.txt root@RoPi:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 700000 root@RoPi:~# /opt/vc/bin/vcgencmd measure_clock arm frequency(45)=700000000 root@RoPi:~# root@RoPi:~# /opt/vc/bin/vcgencmd get_config int program_serial_random=1 config_hdmi_boost=2 disable_commandline_tags=2 emmc_pll_core=1 hdmi_force_cec_address=65535 framebuffer_ignore_alpha=1 framebuffer_swap=1 temp_limit=85 force_pwm_open=1 pause_burst_frames=1 avoid_fix_ts=1 root@RoPi:~#
Pi-2-B:
Spoiler anzeigen
Code
Alles anzeigenroot@pi2:~# uname -a Linux pi2 3.18.6-v7+ #754 SMP PREEMPT Sun Feb 8 20:34:22 GMT 2015 armv7l GNU/Linux root@pi2:~# cat /boot/config.txt root@pi2:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 600000 root@pi2:~# /opt/vc/bin/vcgencmd measure_clock arm frequency(45)=600000000 root@pi2:~# root@pi2:~# /opt/vc/bin/vcgencmd get_config int arm_freq=900 sdram_freq=450 over_voltage_avs=0x1b774 disable_l2cache=1 program_serial_random=1 config_hdmi_boost=2 disable_commandline_tags=2 emmc_pll_core=1 hdmi_force_cec_address=65535 ignore_lcd=1 framebuffer_ignore_alpha=1 framebuffer_swap=1 arm_control=0xa5800010 temp_limit=85 force_pwm_open=1 pause_burst_frames=1 avoid_fix_ts=1 root@pi2:~#
-
Das werde ich vielleicht sogar mal schaffen heute Abend auszuprobieren. Werd auch gleich mal schauen, wie es beim B+ aussieht. Da kann ich mich aber auch wie Du schon geschrieben hast an 700.000.000 erinnern.
-
Achja, bevor ichs vergesse:
Das Kompilieren mit dem Pi2 geht ja nun wesentlich(!!!) schneller, aber
Führt man nur ganz normal " make " aus wird nur ein Core verwendet, aber die restlichen 3 langweilen sich. Das mal zu vergessen kann Stunden warten ausmachen.Der Trick ist dem "make" Befehl vorzuschreiben 4 Cores zu verwenden, was man mit dem Parameter -j erreicht. Also:
Wenn man sich dann neu anmeldet und künftig nur noch " make " eingibt, wird stattdessen " make -j4 " ausgeführt, und was zuvor noch über ne Stunde gedauert hat ist dann in wenigen Minuten fertig
//EDIT:
Man kann übrigens (das ist allgemein Linux) dem Kernel auch sagen das er einen Core nicht für "irgendwelche" Programme verwenden soll... Damit könntet ihr ein Programm diesem Core dann zuweisen und verhindert so das andere Prozesse sich auch an diesem Core nähren bzw Aufmerksamkeit abjagen.
Das erreicht man in dem man /boot/cmdline.txt die Option hinzufügt:
Damit wird Linux verboten den 1.Core zu verwenden (0 - 3 sind die cpu_id's). Zum übernehmen rebooten.
Öffnet anschließend htop seht ihr das 1 sich langweilt.
Anschließend kann man mithilfe des Tools taskset entweder direkt ein Programm starten und sagen welchen Core es nutzen soll. Wenn ihr also ein Programm oder Script habt was ganz alleine auf einem Core laufen soll, egal ob alle anderen gerade voll ausgelastet sind, ist das eine gute Möglichkeit
Aber beachtet das Linux das eigentlich bereits sehr gut managed. Manuell mit taskset alles mögliche zu verstellen kann das ganze auch verschlechtern!(quelle)
-
So habe mich mal rangesetzt und mir erstmal nur den 2B vorgenommen.
zeigt
das ist schon mal ok.
liefert logischerweise
liefert nämlich
Alle obigen Zeilen zeigen die Vorgaben durch die Hardware. Die Taktfrequenz wird durch den s.g. Scaling-Governor gemanaged.
meigrafd: Nicht böse gemeint, aber jetzt kommt Dein Denkfehler.
dann fährst du mit der Standardtaktung, der ab Werk Taktung. Beim alten Pi ist das 700MHz, beim neuen aber 600MHz!
Du bist ungehalten, weilnur
liefert.
Das kommt zustande, weil der Governor "ondemand" gesetzt ist, was soviel heißt wie bei Bedarf. Bei dem bisschen, was gerade läuft braucht der Chip also keine höhere Taktung. Lass mal was im Hintergrund laufen und Du wirst sehen er beginnt zu sausen. Man kann den Governor auch auf "performance" stellen, dann jagd der Prozessor immer mit vollen 900MHz. Das ist aber unnötig und kostet Strom.
Um es nochmal zu betonen, die 600MHz sind keine Standardtaktung sondern dynamisch und bei Deiner Messung am unteren Rand, weil der RasPi nicht belastet ist.Übrigens der Effekt, dass der B+ von Anfang an schneller läuft ist einfach zu erklären. Seine untere vom Governor zu verwaltende Grenze ist 700 MHz.
Hoffe ich konnte ein wenig Licht ins Dunkel bringen.
-
Nein, du verstehst das leider immer noch nicht. Bezgl. Governor usw ist mir das schon klar.
Vergleicht man unter exakt gleichen Bedingungen den alten mit dem neuen, ist der Takt beim neuen niedriger als der Wert mit welchem er verkauft wird!
In den Pi-2 Spezifikationen steht das es sich um einen QuadCore @ 900MHz handelt.
Beim alten Pi-1 steht das es sich um einen SingleCore @ 700MHz handelt.
Beide Systeme mit identischen Images, Einstellungen oder sonst was, keine Belastung usw -> Pi1 läuft mit den offiziell angegebenen 700MHz aber der Pi2 läuft nur mit 600MHz.
Ist mir schon klar das er bei Belastung auch höher getaktet werden kann - das ist hier aber völlig unwichtig! Auch der Pi1 kann bei Bedarf höher getaktet werden. Aber der alte PI wird als 700MHz verkauft, der neue aber als 900MHz!
-
In den Pi-2 Spezifikationen steht das es sich um einen QuadCore @ 900MHz handelt.
Beim alten Pi-1 steht das es sich um einen SingleCore @ 700MHz handelt.
Beide Systeme mit identischem Images, Einstellungen oder sonst was, keine Belastung usw -> Pi1 läuft mit den offiziell angegebenen 700MHz aber der Pi2 läuft nur mit 600MHz.Ich will nicht streiten, aber das muss geklärt werden, denke ich. Es handelt sich doch um 2 verschiedene Architekturen. Der Pi1 läuft mit 700MHz, weil der Hardwaremäßig nichts anders kann, es sei denn man zwingt Ihn dazu. Der QuadCore ist so gebaut, dass er im Standard so wenig Energie wie möglich benötigt, also im "Ruhezustand" mit seiner minimal möglichen Frequenz von 600MHz läuft, egal erst mal, was für ein Image benutzt wird. Das ist hardwaremäßig so gebaut. Trotzdem ist und bleibt er ein 900MHz Core. Sobald irgend eine Rechenleistung benötigt wird fährt der sofort auf seine 900MHz. Die Behauptung er würde nur mit 600MHz laufen ist schlichtweg falsch!
-
Jetzt mitmachen!
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!