+-Serie DS216+ CPU-Frequenz

[Matthieu]

Für den Kernel meiner DS916 habe ich kein turbostat fertig kompilliert auftreiben können. Meine 916 hat auch derzeit keine make-Umgebung und ich möchte das auch nicht ändern. Wenn mir jemand eine fertig kompillierte Version von turbostat bereitstellt, teste ich gerne. Aber so ist mir der Aufwand zu hoch, denn:
Das Bild auf der DS ist bisher identisch zu meinem Test bei einem frischen Ubuntu-System. Dort funktioniert es nachweislich. Ergo habe ich keinen Grund an der DS zu zweifeln.

MfG Matthieu

 

[raffnix84]

@ raffnix84
Du hast geschrieben: "Es geht mir in erster Linie nicht darum wie viele Kerne und wie hoch diese boosten. Es geht darum das der Takt sich egal unter welchem Zustand GAR NICHT
ändert... keine einziger Core und kein einziges MHz."

Das stimmt allerdings nicht, sowohl peterhoffmann als auch Tommes haben doch getestet und da hat die CPU zumindest sauber auf 0,48 GHz runtergetaktet.
Und wenn es dir nur darum geht, daß sich der Takt gar nicht ändert, dann wäre deine Anfrage wohl damit hinfällig.

Das sieht bei mir ein wenig anders aus:

admin@xxx:/$ cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
1601000 42569166
1600000 1772
1520000 0
1440000 0
1360000 0
1280000 0
1200000 0
1120000 0
1040000 0
960000 0
880000 0
800000 0
720000 0
640000 0
560000 0
480000 0

daher habe ich eine andere Ausgangslage. Außerdem heißt es ja nicht dass wenn die CPU bei peterhoffmann und Tommes runter taktet, dass die auch richtig bursted.

 

[raffnix84]

Du bist der feuchte Traum eines jeden Verkäufers.
...
Was versteckt sich wirklich hinter 1601?

Die Antwort findet sich hier: http://www.heise.de/ct/hotline/Turbo-Boost-unter-Linux-861189.html

Bei korrekter Konfiguration sollte sich unter den im Sys-Dateisystem abgelegten Cpufreq-Angaben zu den verfügbaren Taktstufen eine finden, die 1 MHz über der Normalfrequenz des Prozessors liegt. Ferner können Sie versuchen, bei einem ansonsten unbelasteten System zwei CPU-Kerne voll zu belasten (etwa mit md5sum) – wechselt dann die Taktfrequenz von zwei CPU-Kernen auf die höchste zuvor ausgelesene Stufe, während die anderen auf der niedrigsten Stufe bleiben, dann funktioniert Turbo Boost wahrscheinlich richtig.

 

[raffnix84]

Der Finale Stand vom Support:

Die Entwickler haben mir mitgeteilt, dass Sie die aktuelle Frequenz nicht mit den DSM Tools erkennen können.

Die Frequenz '1601000' ist ein Repräsentant für den Turbo Modus. Der Turbo Modus ist im DSM eingeschaltet.

admin@syno:/$ cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state

1601000 102557
1600000 754
1520000 0
1440000 0
1360000 0
1280000 0
1200000 0
Noch mal zur Sicherheit, da im Forum der Turbo Burst mit einem Übertakten im Voll Betrieb verwechselt wird. Der Turbo Modus taktet nur einen Kern hoch und nur wenn kein weiterer Kern genutzt wird. Es wird dann der Wärmehaushalt der anderen Kerne zum Übertakten des einen Kerns genutzt.

Wenn 100% Auslastung im Ressourcen Monitor angezeigt wird, dann wird der Turbo nicht aktiviert werden. Maximal bei 25% (quad core) /50% (dual core).

So wie ich das verstanden habe hat eine CPU eine Bestimmte Anzahl von States / Stromspar Modi - sagen wir Beispielsweise C0 - C10 . Im Idle wird der kleinste C State vom BIOS gewählt C0 und bei Last regelt das BIOS? (Treiber? /CPU?) den C State hoch bis zum "Normalen" C State C7. Wenn nur ein Kern ausgelastet wird & Thermisch alles ok wird auch der C10 State gewählt. Das OS hat keine Möglichkeit die MHz direkt aus der CPU auszulesen, bekommt aber die unterschiedlichen States der CPU mit (evtl steuert das OS sie sogar selbst). Um dem User einen Takt anzeigen zu können gibt es (meine Theorie) eine Art Lookup Table in der hinter der CPU und dem entsprechenden C State eine MHz zahl steht. Hier gibt es auch vermutlich eine Art Fallback Profile wenn die CPU nicht gefunden wird so das eine Art Legacy Profil für die "Braswell" oder "Celeron N" Gruppe. Ich denke das es genau hier der Fall ist da der Kernel nicht mehr der frischeste ist. Der C10 State wird zwar erreicht (laut BIOS 2.54GHz) aber laut der veralteten wird dann lediglich 1.601MHz angezeigt.

Mann könnte das Prüfen indem man z.B. ein Ubuntu 16.04 auf dem Board hier installieren würde:
https://www.alternate.de/ASRock/J3710M-inkl-Intel-Celeron-N3170-Mainboard/html/product/1270112

Somit bleiben wir ausschließlich im spekulativen Bereich hängen da selbst der Synology Support keine Methode zur Überprüfung anbieten kann.
Ich weiss noch nicht genau was ich davon halten soll..

 

[arghmage]

Gibts was Neues zu dem Thema? (oder war es doch nur ein Sturm im Wasserglas?)

 

[raffnix84]

Naja wie ich oben bereits ausgeführt habe kam vom Support ein "das ist so"... wir können es nicht beweisen und sie können es nicht überprüfen aber CPU Hersteller hat gesagt das es so ist also ist es so.... bin mit der Antwort hochgradig unzufrieden, Die QNAPs sind im übrigen aber genau so betroffen da hier auch wie beider der Synology ein "uralt" Linux Kernel zum Einsatz kommt..

 

[arghmage]

Wobei das "die QNAPs sind genauso betroffen" auch wieder nur eine Vermutung ist

 

[Iarn]

da hier auch wie beider der Synology ein "uralt" Linux Kernel zum Einsatz kommt..

Diese Woche wird Synology übrigens das Kunststück vollbringen, ganze 20 Kernelversionen hinter dem Mainline Kernel zurück zu hängen.

 

[raffnix84]

Wobei das "die QNAPs sind genauso betroffen" auch wieder nur eine Vermutung ist

Keine Vermutung... Tatsache...!

Dieselbe Vermutung habe ich auch, ich habe heute das selbe Problem mit einem QNAP TS-453A (Celeron N3160) nachstellen können.

Somit sehe ich hier ganz klar den Kernel als Zusammenhang. (Synology: 3.10 / QNAP: 3.19)

...

 

[raffnix84]

Diese Woche wird Synology übrigens das Kunststück vollbringen, ganze 20 Kernelversionen hinter dem Mainline Kernel zurück zu hängen.

Meeega!
Wo hast du die Infos her? Gibt es da einen Artikel/Changelog/Thread zu? Kannst du das velinken?

 

[Iarn]

uname -a gibt auf einem Linux System die Kernel Version aus

Kernel 4.10 wurde released, heute werden einige early Adopter inklusive mir (für das Kaby Lake Ultrabook) den neuen Kernel aufspielen, Synology nutzt noch 3.10, das sind 20 Versionen Delta.

 

[raffnix84]

Super! Danke für die Info und viel Erfolg bei Testen.

 

[Scirocco3]

Und selbst die "aktuelle" Beta DSM 6.1 ändert daran nix ;-)
Das ist immer noch 3.10.102

 

[Matthieu]

Es gibt durchaus eine Lösung: turbostat kompilieren. Ich habe es schon mal gesagt. Wem so viel daran liegt, der sollte es kompilieren und ausprobieren. Mir reicht als Nachweis die 1601.
Sonst beschwere dich doch mal bei Intel dass die CPU keine LED hat um anzuzeigen was sie tut. Oder noch schöner ein Display mit Anzeige von Takt, Temperatur usw.

MfG Matthieu

 

[raffnix84]

Es gibt durchaus eine Lösung: turbostat kompilieren. Ich habe es schon mal gesagt. Wem so viel daran liegt, der sollte es kompilieren und ausprobieren. Mir reicht als Nachweis die 1601.
Sonst beschwere dich doch mal bei Intel dass die CPU keine LED hat um anzuzeigen was sie tut. Oder noch schöner ein Display mit Anzeige von Takt, Temperatur usw.

MfG Matthieu

Öhhm ja... genau... ich der ein NAS betreibt um seine Backups und seine wertvollsten Daten relativ ausfallsicher lagern will installiere jetzt "irgendwas" (diverse libraries, headers etc.)
wovon ich überhaupt keine Ahnung habe auf dem system und fange an irgendwelche sachen zu compilieren und tonnen von dependencies nachzuinstallieren...
wo ich nicht genau sagen kann ob das system am ende noch genau so läuft.... nein Danke!

Ich heisse zwar raffnix aber blöd bin ich trozdem nicht. Ausserdem glaube ich nicht das der aktuell turbostat Quellcode auf dem Synology UrAlt Kernel überhaupt kompiliert.
Altes turbostat habe ich ohne erfolg bereits getestet.

Wie dem auch sei, wenn du es kannst und die Gemeinde bereichern möchtest kanns du gerne turbostat kompilieren und und uns mit deinen Erkentnissen bereichern.

Warum soll ich den Fehler bei INTEL suchen wenn synology hier veraltete Software mit moderner Hardware nicht verheiratet bekommt?
Ubuntu 16.04 (4.9.5 Kernel) auf meinem Notebook kann das ohne turbostat auch... von daher hinkt dein Einwand nicht unerheblich.

$ cat /proc/cpuinfo | grep -i MHz
cpu MHz : 499.914
cpu MHz : 499.914
cpu MHz : 499.914
cpu MHz : 499.914

$ cat /proc/cpuinfo | grep -i MHz
cpu MHz : 775.451
cpu MHz : 499.914
cpu MHz : 540.869
cpu MHz : 515.356

$ cat /proc/cpuinfo | grep -i MHz
cpu MHz : 1158.679
cpu MHz : 1682.763
cpu MHz : 1225.683
cpu MHz : 1697.399

Gruss

 

[geimist]

Es gibt durchaus eine Lösung: turbostat kompilieren.

Ein fertig kompiliertes Turbostat-Binary gibt es hier: https://thingshardtofind.blogspot.de/2012/05/ubertakten-unter-linux-echten-cpu-takt.html

 

[goetz]

Hallo,
leider gibt es aber das Kernelmodul msr nicht. Das Programm läuft, wirft aber /dev/cpu/4/msr: No such file or directory aus. Alle folgenden Frequenzangaben ändern sich nicht, egal ob Last oder Langeweile.

Gruß Götz

 

[geimist]

OK, dann war ich wieder mal zu vorschnell …

Grundsätzlich vorweg: Mir reicht eigentlich auch als Nachweis die Info 1601, wie von Matthieu geschrieben, finde das Thema aber interessant.
Um die Annahme, dass alles Korrekt ist, zu fundieren hatte jetzt einfach mal eine Audiodatei per ffmpeg von mp3 zu aac konvertiert. Das lastet schön einen Kern aus (12,5 fache Geschwindigkeit). Ich würde jetzt erwarten, dass zwei gleichzeitig gestartete Konvertierungen die Konvertiergeschwindigkeit herabsetzt und die Ausführungszeit verlängert. Dem war aber nicht so. Obwohl ich darauf geachtet hatte, dass die DS im Idle ist, kann es natürlich dennoch sein, dass irgendwelche Prozesse den restlichen Kernen nicht genügend Ruhe gönnten.

Vielleicht liege ich auch mit dieser Annahme völlig daneben.

Gute Nacht

 

[raffnix84]

Ein fertig kompiliertes Turbostat-Binary gibt es hier: https://thingshardtofind.blogspot.de/2012/05/ubertakten-unter-linux-echten-cpu-takt.html

Danke für die Info, habe es nochmal probiert und exakt das selbe Problem wie Götz gehabt (DSM 6.1).

Im Grunde genommen verhält sich turbostat genau so wie ich es bereits vor 4 Monaten hier beschrieben habe allerdings kann ich nicht genau sagen wo ich da die Binary her hatte weil ich zu viele ausprobiert hatte.
http://www.synology-forum.de/showthread.html?74847-DS216-CPU-Frequenz&p=660317&viewfull=1#post660317

Der Status bleibt somit: "You have to believe".

Nochmal zur Klarstellung, ich habe keine "Bauchschmerzen" oder "Panik"... ich glaube ja das die CPU Hardware seitig boosten aber ich als Entwickler habe schon so viel "Stuss" gesehen das ich nach dem Prinzip
"Vertrauen ist gut Kontrolle ist besser" verfahre und daher den Beweis (bitte nicht persönlich angesprochen fühlen, ich meine im allgemeinem) einfordere.

Wenn ich das ganze richtig verstanden habe so steht die 1601Mhz symbolisch für den C0 (Höchster Boost) State bei dem laut Intel Datenblatt die CPU je nach Core Auslastung auf 2.56Ghz takten sollte. Ich finde es verwirrend dass meine CPU niemals einen anderen Wert als 1601 anzeigt... denn das würde ja Bedeuten alle Cores immer boosten... und selbst wenn nicht alle boosten müsste es ja im Umkehrschluss heißen das meine CPU niemals Idelt und sich herunter taktet...

Daher reichen mit persönlich die 1601Mhz nicht denn es passt nicht ganz in mein Verständnis, zweifellos kann es auch an meinem Verständnis hapern aber hier konnte mich nicht ein mal der Synology Support aufklären, den
ich durchaus als kompetent empfand.

Gruss

 

[geimist]

+1