Raspberry 2 erscheint

L I V E Stammtisch ab 20:30 Uhr im Chat
  • [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. :wallbash:

    :)

  • Bitte bleibt sachlich. Es fehlt uns immer die interne Information!
    Schwiene gehört hier nicht hin. :wallbash:

    "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

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (10. Februar 2015 um 12:11)

  • 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)!

    Einmal editiert, zuletzt von michaMEG (10. Februar 2015 um 12:40)

  • Gestern kam meiner an.
    Jörg hat wirklich schnell verschickt ;)

    Lä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.

    Offizieller Schmier und Schmutzfink des Forum.
    Warum einfach wenn's auch schwer geht ?

    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.

  • 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 " :-/

    Code
    root@raspberrypi:~# grep tre /boot/config.txt                                                                              
    root@raspberrypi:~#

    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:

    Code
    root@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:

    Code
    ERROR: could not insert 'spi_bcm2708': No such device

    Nunja... Erstmal egal, ich muss ja nicht alles verstehen :lol:


    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... :denker: 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:

    Code
    3.18.5-v7+ #225 SMP PREEMPT Fri Jan 30 18:53:55 GMT 2015 armv7l GNU/Linux

    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

    Code
    3.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 :mad_GREEN:

    Die Standard Konfiguration, die laut vcgencmd get_config int angeblich aktiv sein soll, sieht wie folgt aus:

    (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 :huh:

    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

    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-line

    Nach ü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 :bravo2: 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 ignorieren :fies:

    Die 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 :baeh2:

    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 kleckern :D


    So als letzter Test den ich jetzt noch mache bevor ich mich an mein eigentliches Vorhaben setze, wäre eine gnadenlose Übertaktung und stresstest :daumendreh2:

    1. Versuch:

    Code
    force_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 :fies:
    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!! :P :auslachen:

    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 :angel: 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 ;)

  • :auslachen: 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 Eintrag

    Code
    device_tree=

    DT aktiviert ist. Da wird auch nichts auskommentiert. Erst nachdem Du "device tree disabled" gewählt hast wird der Eintarg

    Code
    device_tree=

    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.

  • 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?

  • meigrafd

    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.

    ;) Gruß Outi :D
    Pis: 2x Pi B (Rente) / 1x Pi B+ (Rente) / 1x Pi 2 B (Rente) / 2x Pi 3 B (RaspberryMatic / Repetier Server) / 2x Pi Zero 1.2 (B. Lite) / 2x Pi Zero 1.3 (B. Lite) / 2x Pi Zero W 1.1 (B. Lite) / 1x Pi Zero 2 (mal so, mal so) / 1x Pi 3 B+ (Tests) / 1x Pi 4 B 4GB (BW Lite (Webserver)) / Pi 400 (BW) / 1x Pi 5 (BW) / 2x Pi Pico / 2x Pi Pico W
    Platinen: Sense HAT / HM-MOD-RPI-PCB / RPI-RF-MOD / PiFi DAC+ V2.0 / TV HAT / Pi 5 Kühler HAT
    Kameras: orig. Raspberry Pi Camera Module V1 & V3 / PS3 Eye

  • 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.

    Code
    arm_freq=900

    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

    Pi-2-B:

    Spoiler anzeigen
  • 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:

    Code
    echo "alias make='make -j4'" >> ~/.bashrc

    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 :angel:

    //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:

    Code
    isolcpus=0

    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 :fies:
    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.

    Code
    cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies

    zeigt

    Code
    600000 900000

    das ist schon mal ok.

    Code
    cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq

    liefert logischerweise

    Code
    600000
    Code
    cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

    liefert nämlich

    Code
    900000


    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, weil

    Code
    /opt/vc/bin/vcgencmd measure_clock arm

    nur

    Code
    600000000

    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!