Tiefe C-States werden mit USB-DVB auf einem Core nicht erreicht

Ich habe die letzten Tage mal versucht, mich in die Energieverwaltung einzuarbeiten, bleibe aber an einer Frage hängen...

Mainboard: ASUS H97M-E
Prozessor ist ein i3-4370

Kernel: 4.4.21-gentoo

Daran hängt ein 'Bus 003 Device 003: ID 14f7:0500 TechniSat Digital GmbH DVB-PC TV Star HD' USB-DVB-S-Empfänger.

Ausgabe cpupower:

vdr ~ # cpupower frequency-info
analysiere CPU 0:
  Treiber: intel_pstate
  Folgende CPUs laufen mit der gleichen Hardware-Taktfrequenz: 0
  Die Taktfrequenz folgender CPUs werden per Software koordiniert: 0
  Maximale Dauer eines Taktfrequenzwechsels: 0.00 ms.
  Hardwarebedingte Grenzen der Taktfrequenz: 800 MHz - 3.80 GHz
  mögliche Regler: performance, powersave
  momentane Taktik: die Frequenz soll innerhalb 800 MHz und 3.80 GHz.
                    liegen. Der Regler "performance" kann frei entscheiden,
                    welche Taktfrequenz innerhalb dieser Grenze verwendet wird.
  momentane Taktfrequenz ist 3.80 GHz  (verifiziert durch Nachfrage bei der Hardware).
  boost state support:
    Supported: no
    Active: no

Nun zum Problem:
Mit i7z (git von gestern) habe ich überprüft, wie tief die beiden Kerne einschlafen. Dabei ist mir aufgefallen, daß ein Kern regelmäßig in den Tiefschlaf C7 geht, während der zweite Kern in C1 hängen bleibt. Die Prozessorlast ist dabei insgesamt nur knapp über Grundrauschen.
Nach Beendigung von vdr gehen beide Kerne in C7, die Temperatur sinkt schnell um 5°C.
Nähere Recherche hat ergeben, daß es ausreicht, den USB-Stecker des DVB-Adapters zu ziehen für den gleichen Effekt.

Ausgabe i7z:

Cpu speed from cpuinfo 3791.00Mhz
cpuinfo might be wrong if cpufreq is enabled. To guess correctly try estimating via tsc
Linux's inbuilt cpu_khz code emulated now
True Frequency (without accounting Turbo) 3791 MHz
  CPU Multiplier 38x || Bus clock frequency (BCLK) 99.76 MHz


Socket [0] - [physical cores=2, logical cores=4, max online cores ever=2]
  TURBO DISABLED on 2 Cores, Hyper Threading ON
  Max Frequency without considering Turbo 3791.00 MHz (99.76 x [38])
  Max TURBO Multiplier (if Enabled) with 1/2/3/4 Cores is  38x/38x/38x/38x
  Real Current Frequency 3791.19 MHz [99.76 x 38.00] (Max of below)
        Core [core-id]  :Actual Freq (Mult.)      C0%   Halt(C1)%  C3 %   C6 %   C7 %  Temp      VCore
        Core 1 [0]:       3791.19 (38.00x)         1    99.3       0       0       0    42      1.1650
        Core 2 [1]:       3790.00 (37.99x)         1       0       1       1    97.7    39      1.1633


C0 = Processor running without halting
C1 = Processor running with halts (States >C0 are power saver modes with cores idling)
C3 = Cores running with PLL turned off and core cache turned off
C6, C7 = Everything in C3 + core state saved to last level cache, C7 is deeper than C6
  Above values in table are in percentage over the last 1 sec
[core-id] refers to core-id number in /proc/cpuinfo
'Garbage Values' message printed when garbage values are read

Fragen daher: ist das ein normales Verhalten? Kann man das irgendwie optimieren? Wo 5°C Temperatur erzeugt werden, wird ja auch Strom verbraten...

Google habe ich bemüht, aber nichts passendes gefunden.

Christian

hepi: Danke, das macht mir leider wenig Hoffnung...

Für's Protokoll: ich habe mal andere USB-Ports probiert, auch USB2 statt USB3: kein Effekt.

Hier noch i7z ohne laufenden vdr, also mit 'passivere' USB-DVB-Karte.

Cpu speed from cpuinfo 3788.00Mhz
cpuinfo might be wrong if cpufreq is enabled. To guess correctly try estimating via tsc
Linux's inbuilt cpu_khz code emulated now
True Frequency (without accounting Turbo) 3794 MHz
  CPU Multiplier 38x || Bus clock frequency (BCLK) 99.84 MHz


Socket [0] - [physical cores=2, logical cores=4, max online cores ever=2]
  TURBO DISABLED on 2 Cores, Hyper Threading ON
  Max Frequency without considering Turbo 3794.00 MHz (99.84 x [38])
  Max TURBO Multiplier (if Enabled) with 1/2/3/4 Cores is  38x/38x/38x/38x
  Real Current Frequency 3748.24 MHz [99.84 x 37.54] (Max of below)
        Core [core-id]  :Actual Freq (Mult.)      C0%   Halt(C1)%  C3 %   C6 %   C7 %  Temp      VCore
        Core 1 [0]:       3748.24 (37.54x)         1    3.01       1       0    95.8    37      1.1650
        Core 2 [1]:       3743.17 (37.49x)         1    4.09       0       0    95.9    33      1.1682


C0 = Processor running without halting
C1 = Processor running with halts (States >C0 are power saver modes with cores idling)
C3 = Cores running with PLL turned off and core cache turned off
C6, C7 = Everything in C3 + core state saved to last level cache, C7 is deeper than C6
  Above values in table are in percentage over the last 1 sec
[core-id] refers to core-id number in /proc/cpuinfo
'Garbage Values' message printed when garbage values are read

C7 auf beiden Cores, Temp deutlich besser. Das System kann also, darf aber irgendwie nicht.

Christian

Zitat von hepi

Ich habe keinen blassen Schimmer, ob das was hilft, aber Du kannst es ja mal ausprobieren mit rmmod uhci_hcd.

Kein Effekt.

vdr ~ # zgrep HCD /proc/config.gz
CONFIG_USB_ARCH_HAS_HCD=y
# CONFIG_USB_C67X00_HCD is not set
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_EHCI_HCD=y
# CONFIG_USB_EHCI_HCD_PLATFORM is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
# CONFIG_USB_FOTG210_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
# CONFIG_USB_UHCI_HCD is not set
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_HCD_TEST_MODE is not set

Zitat von mini73

Oder mit dem Patch von der ML bzw. dem dynamite Plugin das Gerät regelmäßig schlafen legen. Das müsste auch gehen.

Der Rechner eigentlich nur an, wenn er auch genutzt wird. Das hilft dann nicht.

Christian

Mir geht's ums Prinzip.
Basta.

Christian

Das war eben meine Frage: 'ist das ein normales Verhalten'
Wenn Du sagst, daß das bei USB so zu erwarten ist, dann ist das leider ein normales Verhalten.

Das Gute daran wäre, daß ich das Thema für micht abschließen kann...

Könnte ich dann darauf hoffen, daß das mit einer PCIe-Karte besser wäre?

Christian

Ich habe eine NVidia per PCIe im System als softhddevice-Ausgabe, die stört hier nicht.

Momentan spiele ich gerade mit Dynamit (Kids, don't try that at home). Wenn ich während einer Wiedergabe den USB-Empfänger (einziges DVB-Input-Device) in Idle schicke, geht das System praktisch komplett in C7 und die Temperatur geht in die 30er. Danke SurfaceCleanerZ für die Idee.

Bisher habe ich es aber noch nicht geschafft, daß die Karte automatisch in Idle geht bei Wiedergabe. Aber ich bin optimistisch, daß das lösbar ist...

Christian

So, jetzt sieht's gut aus.
Ich habe nun das dynamite-plugin mit im System. Das schafft es aber -zumindest bei mir- nicht, das einzige vorhandene Input-Device in IDLE zu versetzen, wenn ich eine Aufnahme anschaue.

VDR besitzt leider nur recording-hooks, aber keine replay-hooks, daher habe ich ein wenig gebastelt mit 3 systemd-units und 2 kleinen scripten:

/etc/systemd/system/vdr-replay-monitor.service

vdr ~ # cat /etc/systemd/system/vdr-replay-monitor.service
[Unit]
Description=Log VDR Replays
After=systemd-journald.service


[Service]
Type=simple
ExecStart=/usr/local/bin/vdr-replay-monitor.sh
User=vdr
Group=video


[Install]
WantedBy=multi-user.target

/usr/local/bin/vdr-replay-monitor.sh

vdr ~ # cat /usr/local/bin/vdr-replay-monitor.sh
#!/bin/bash
rm -f /tmp/replay.log
/usr/bin/journalctl -f -q -n0 -u vdr -o cat -p6 | /bin/grep --line-buffered "] replay /" > /tmp/replay.log

Das '--line-buffered' hat mich fast den letzten Nerv gekostet. Ausgabe auf der console klappt auch ohne, aber nicht in eine Datei. Das nur am Rande.

Mit den beiden obigen files suche ich fortlaufend im journal nach replay-Beginn und schreibe das nach /tmp/replay.log.
Diese Datei überwache ich mit einem anderen Service auf Änderungen: vdr-usb-idle.path

vdr ~ # cat /etc/systemd/system/vdr-usb-idle.path
[Unit]
Description=Trigger vdr-usb-idle.service
After=vdr.service


[Path]
PathModified=/tmp/replay.log


[Install]
WantedBy=multi-user.target

/etc/systemd/system/vdr-usb-idle.service

vdr ~ # cat /etc/systemd/system/vdr-usb-idle.service
[Unit]
Description=Send USB-DVB-Device to IDLE
Documentation= man:systemd.service


[Service]
Type=oneshot
ExecStart=/usr/local/bin/vdr-usb-idle.sh
User=vdr
Group=video

und starte dann /usr/local/bin/vdr-usb-idle.sh, welches mir per svdrp das Frontend auf IDLE setzt.

vdr ~ # cat /usr/local/bin/vdr-usb-idle.sh
#!/bin/bash
FRONTEND=/dev/dvb/adapter0/frontend0
LOG=/tmp/replay.log
[ -s $LOG ] && svdrpsend PLUG dynamite SetIdle $FRONTEND
exit 0

Nach Ende der Wiedergabe wird dieses von VDR automatisch wieder aktiviert.

Aktivieren mit:
systemctl enable vdr-usb-idle.path
systemctl enable vdr-replay-monitor.service

Nebeneffekte erwarte ich für mich nicht. Der betroffene Client führt keine EPG-Scans durch und nimmt auch nicht auf.

Vielleicht hilft's ja jemandem. Elegantere Lösungen werden gerne angenommen.

Christian

Zitat von seahawk1986

Statt das Log auszuwerten könnte man auch auf die Signale des dbus2vdr-Plugin lauschen.

Da reicht ein kleines Python-Skript - man bräuchte dann nur eine Systemd-Unit

Danke, ist auch eine Möglichkeit. Muß ich für mich noch abwägen, ob ich lieber die zusätzlichen Units oder ein weiteres Plugin haben möchte.

Eleganter ist die dbus-Variante aber in jedem Fall. Mein journal-grepping ist etwas hemdsärmelig, zugegebenermaßen.

Christian

Zitat von hepi

Im Endeffekt geht es ja ums Stromsparen. Wieviel Energie geht denn netto flöten, wenn einer von zwei CPU-Cores seinen C6/C7 nicht mehr erreicht? Was sagt das Messgerät?

Für's Protokoll: Zwischen Live-TV und Abspielen einer Aufzeichnung (und IDLE wie oben beschrieben) liegen immerhin 10W. Sagt das Schätzeisen.

Christian