Leserechte dauerhaft vergeben (cpuinfo_cur_freq)

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Hallo,

    Ich nutze das Programm PI Control um die Parameter meines RPI2 auszulesen.
    Zum auslesen der aktuellen CPU-Taktrathe liest das Programm die "scaling_cur_freq" unter "/sys/devices/system/cpu/cpu0/cpufreq/" aus.
    Bei meiner Ditribution (OSMC auf Debina Jessie) wird unter "scaling_cur_freq" aber immer nur die maximal mögliche CPU-Taktrathe anzeigt (auch wenn ich diese z.B. über SSH mit "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq" auslese). Mit "cpuinfo_cur_freq" wird mir hingegen immer die aktuelle Taktrathe richtig angezeigt und wechselt zwischen 600 und 900 (Ist das normal, bzw. ihat noch jemand das selbe Problem?).

    Ich würde nun gerne das auslesen der aktuellen CPU-Taktrathe von "scaling_cur_freq" auf "cpuinfo_cur_freq" abändern, was an sich eigentlich kein Problem darstellt.
    In PI Control werden die Werte über eine php-Datei abgefragt und das aulesen geht über "shell_exec". Das Problem dabei ist nur "cpuinfo_cur_freq" hat nur Leserechte für Root und somit muss die Datei über sudo ausgelsen werden (sprich: "shell_exec('sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq'"). Damit das möglich hab ich dann versucht dem Benutzer "www-data" in "/etc/sudoers" Rootrechte für die php-Datei zum auslesen der Statuswerte zu vergeben (mit: "www-data ALL= /var/www/html/resources/library/main/rpifunktion.php") , was aber nicht funktioniert hat (Mit "www-data ALL=NOPASSWD: All" hat es zwar funktiniert, aber ich will dem Benutzer keine rootrechte für alle Dateien vergeben).

    Nun bin ich auf die Idee gekommen einfach der Datei "cpuinfo_cur_freq" Leserechte für alle User zu vergeben, was auch funktioniert hat und PI Control mit jetzt die richtige Taktrathe ausliest und anzeigt.
    Nur nach jedem Neustart sind die erweiterten Leserechte wieder weg und ich müssen neu vergeben werden. Weiß jemand ob ich das irgentwie umgehen bzw. notfals automatisieren kann, das die Leserechte nach einem Neustart automatisch erweitert werden?


    Gruß,
    Harald


  • wechselt zwischen 600 und 900 (Ist das normal, bzw. ihat noch jemand das selbe Problem?).

    Das ist kein Problem sondern normal. Sofern du nicht explizit "force_turbo=1" in /boot/config.txt eingetragen hast, taktet der Pi je nach CPU Auslastung hin und her. Wenn er wenig zu tun hat möchte er Strom sparen und taktet sich runter.

    Guck dir einfach mal die Datei an: /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
    Na, was steht da drin? :)


    In PI Control werden die Werte über eine php-Datei abgefragt und das aulesen geht über "shell_exec". Das Problem dabei ist nur "cpuinfo_cur_freq" hat nur Leserechte für Root und somit muss die Datei über sudo ausgelsen werden (sprich: "shell_exec('sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq'"). Damit das möglich hab ich dann versucht dem Benutzer "www-data" in "/etc/sudoers" Rootrechte für die php-Datei zum auslesen der Statuswerte zu vergeben (mit: "www-data ALL= /var/www/html/resources/library/main/rpifunktion.php") , was aber nicht funktioniert hat (Mit "www-data ALL=NOPASSWD: All" hat es zwar funktiniert, aber ich will dem Benutzer keine rootrechte für alle Dateien vergeben).

    Du hast da noch nicht verstanden wie "sudo" funktioniert. Der Befehl welcher über "sudo" ausgeführt wird ist nicht /var/www/html/resources/library/main/rpifunktion.php und somit ist klar das der Eintrag nicht funktioniert.


    Nur nach jedem Neustart sind die erweiterten Leserechte wieder weg und ich müssen neu vergeben werden. Weiß jemand ob ich das irgentwie umgehen bzw. notfals automatisieren kann, das die Leserechte nach einem Neustart automatisch erweitert werden?

    Naja das virtuelle sysfs wird durch den Kernel generiert und das bei jedem neustart natürlich... Quick and Dirty wäre dein chmod Befehl einfach in /etc/rc.local einzutragen. Schöner wäre es allerdings über udev

    Was aber wichtig ist:

    Bitte nutze weiterhin die Datei /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

    Ich glaube du hast nur nicht gewusst dass es beim Pi normal ist das er hin und her taktet und dachtest daher du müsstest an "PI Control" herum pfuschen.... Bitte nicht ;)

  • Was aber wichtig ist:

    Bitte nutze weiterhin die Datei /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

    Ich glaube du hast nur nicht gewusst dass es beim Pi normal ist das er hin und her taktet und dachtest daher du müsstest an "PI Control" herum pfuschen.... Bitte nicht ;)

    Hallo meigrafd,

    ich glaub ich hab mich falsch ausgedrückt.
    Mir ist bewusst das der Pi zwei Taktstufen hat und genau diese verscheiden Takstufen würde ich gerne auslesen bzw. anzeigen ;)
    Leider geht das bei mir mit "scaling_cur_freq" nicht, da mir "scaling_cur_freq" immer als aktuellen Takt den maximalen Takt anzeigt.
    Mit der Frage ob das normal ist, meinte ich ob es normal ist dass "scaling_cur_freq" immer den maximalen Takt anzeigt und nur "cpuinfo_cur_freq" mir den richtigen Takt anzeigt?
    (Zufdem müssten diese doch eigentlich identisch sein oder?)


    Du hast da noch nicht verstanden wie "sudo" funktioniert. Der Befehl welcher über "sudo" ausgeführt wird ist nicht /var/www/html/resources/library/main/rpifunktion.php und somit ist klar das der Eintrag nicht funktioniert.

    da liegst du warscheinlich richtig :) , heißt das ich muss den Pfad zu "cpuinfo_cur_freq" angeben, also "www-data ALL= /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq"?


    Naja das virtuelle sysfs wird durch den Kernel generiert und das bei jedem neustart natürlich... Quick and Dirty wäre dein chmod Befehl einfach in /etc/rc.local einzutragen. Schöner wäre es allerdings über udev

    Kannst du mir sagen wie das mit udev dann aussehen müsste?

    Einmal editiert, zuletzt von Harald654 (10. August 2016 um 00:56)

  • Hm das kann ich grad nicht nachvollziehen:

  • Ich find das auch sehr komsich. Hab aber inzwischen mal im OSMC Forum nachgefragt und scheint wohl gewollt zu sein!

    Der Entwickler Sam schrieb mir:

    Zitat

    Yes -- it's intentional. I mount --bind the max_freq over the current scaling frequency. This is so that user's don't get confused and think there system is underclocked.

    Somit bleibt mir wohl nichts anderes übrig als die Taktrate über "cpuinfo_cur_freq" auszulesen, oder kann man das irgentwie wieder rückgänig machen?


    Gruß,
    Harald

  • Ich steh grad aufm Schlauch.... Wieso mounted man scaling_cur_freq über cpuinfo_cur_freq ? :s Wie ich oben gepostet habe geben beide Dateien die selben Werte aus


    BTW: Kennst du schon mein RPI_Info Windows-Gadget oder meine cpu.php oder diese raspberrypi.class.php ?


  • Ich steh grad aufm Schlauch.... Wieso mounted man scaling_cur_freq über cpuinfo_cur_freq ? :s

    Tut er ja nicht, es wird max_freq über cur_freq gemountet, weil Teile der OSMC-Userschaft anscheinend zu dämlich sind, dynamische CPU-Taktung zu verstehen.

    Wenn du nichts zu sagen hast, sag einfach nichts.

    Einmal editiert, zuletzt von llutz (10. August 2016 um 11:31)


  • Ich steh grad aufm Schlauch.... Wieso mounted man scaling_cur_freq über cpuinfo_cur_freq ? :s Wie ich oben gepostet habe geben beide Dateien die selben Werte aus

    Zitat

    Yes -- it's intentional. I mount --bind the max_freq over the current scaling frequency. This is so that user's don't get confused and think there system is underclocked.

    Also: Nicht scaling_cur_freq, sondern cpuinfo_max_freq wird über cpuinfo_cur_freq gemountet, um die Nutzer nicht zu verwirren. Inwiefern das sinnvoll ist und dieses Ziel erreicht, mag jeder für sich selbst beurteilen - ich finde es eher abwegig.

    • Offizieller Beitrag

    wie man sieht hat es ein Haufen Leute verwirrt. warum man sich aber die aktuelle Taktfrequenz unbedingt anschauen muss versteh ich eh nicht? Macht ihr das am Heim PC auch? Jetzt ist er bei 0.86GHz, nein 0.91...wieder 0.86. Was für ein Kopf an Kopfrennen meine Damen und Herrer :denker: ;)

    Der Unterschied zwischen Genie und Wahnsinn definiert sich im Erfolg.


  • wie man sieht hat es ein Haufen Leute verwirrt. warum man sich aber die aktuelle Taktfrequenz unbedingt anschauen muss versteh ich eh nicht? Macht ihr das am Heim PC auch? Jetzt ist er bei 0.86GHz, nein 0.91...wieder 0.86. Was für ein Kopf an Kopfrennen meine Damen und Herrer :denker:


    Auf meinm RPI laufen neben OSMC (bzw Kodi) noch relaitv viele andere Dienste permanent (mysql, smb, usw), darum hab ich ihn für den flüssigen Betrieb von Kodi relativ stark übertakten. ich will den Takt daher wissen, um zu sehen wie Ausgelastet mein RPi ist und ob er noch im Idle (also wenn ich Kodi gerade nicht verwende) runtertaktet oder ob die ganzen Dienste ihn dauerhaft auf max. Takt halten (was bei 24h nicht gerade förderlich für die Lebensdauer wäre). ;)


    Wie ist denn die Ausgabe von "mount"? Du könntest ein "sudo umount /sys/.../scaling_cur_freq" versuchen.


    der Mount von "cpuinfo_max_freq" auf "scaling_cur_freq" befindet sich in der Datei "/usr/bin/mediacenter"
    Hab die entsprechenden Stellen auskommentiert, nun wird mir wieder der aktuelle Takt angezeigt :)
    xr5wm9a7.png
    ("umunt -l /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq" hat auch funktioniert, nur war es nach einem Neustart wieder mountet)

    Soweit passt jetzt also alles wieder :thumbs1: , nur verwende ich eine Betaversion von OSMC (wegen Kodi 17) wofür fast täglich ein neues Image/Update erscheint und mir mein Fix in "/usr/bin/mediacenter" wieder aufhebt. Somit muss ich nach jedem Update über "sudo nano" die Datei "/usr/bin/mediacenter" öffnen, den mount suchen und auskommentieren....
    Hat jemand eine Idee wie ich es verinfachen (oder automatisieren) könnte die Datei /usr/bin/mediacenter" nach einem Update zu bearbeiten, oder alternativ automatisch nach einem neustart die Datei /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq wieder unmonte?

    Gruß,

    Einmal editiert, zuletzt von Harald654 (10. August 2016 um 18:29)

  • Anhand des Takts ablesen ob oder wie der Rechner ausgelastet ist, ist eher untypisch... Wieso nimmst du dafür nicht die Werte aus /proc/loadavg ? Die ersten 3 Werte beziehen sich auf die durchschnittliche Auslastung der 1) letzten Minute 2) letzten 5 Minuten 3) letzten 15 Minuten. Eine weitere aber komplizierte Ermittlung geht über /proc/stat .. Siehe dazu RPi_Info und cpu.php

    Ein dauerhafter Fix könnte ggf über schon erwähnte /etc/rc.local geregelt werden, sofern diese später ausgeführt wird als /usr/bin/mediacenter ... Allerdings muss /usr/bin/mediacenter auch irgendwo drin stehen, entweder im systemd oder sysVinit , denn einfach so kann es ja nicht automatisch gestartet werden. Am besten wäre also dort den jeweiligen Eintrag zu modifizieren wenn es beispielsweise über sysVinit und somit /etc/init.d/ gestartet wird...

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!