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:


    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:


    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.


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


    Christian

  • Das Gute bei Dir ist doch, dass zumindest einer der CPU-Kerne rumdümpelt im C7. Das ist doch schonmal besser als gar nichts.


    Auf einigen älteren Linux-Powersaving-Seiten liest man, man könne das Kernelmodul "uhci_hcd" für die Kommunikation mit USB 1.1 Geräten blacklisten oder entfernen, solange man keine uralten USB 1.1-Geräte verwendet.
    Ich habe keinen blassen Schimmer, ob das was hilft, aber Du kannst es ja mal ausprobieren mit rmmod uhci_hcd.


    Gruß
    hepi

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


    Lars

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


    Kein Effekt.



    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

  • Hmm, warum benutzt du dann USB?



    USB beruht auf Polling. Die CPU wird doch sicherlich beim Pollen periodisch beschäftigt werden - wie soll das gehen wenn alle cores tief schlafen?

  • 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

  • Hi,
    wenn du Strom sparen willst, dürfte dyamite auch im Betrieb helfen!


    MfG,
    Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

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


    Bei meinen Tests in 2014 (Link oben) mit meiner Hardware habe ich bei mindestens einer gesteckten PCIe-Karte auch keine tiefen C-States mehr erreicht.
    Kommt also konkret auf Deine Hardware und deren Treiber an, würde ich mal so raten... (raten im Sinne von schätzen)


    Allerdings gab es hier mal jemanden, der tiefe C-States erreichen konnte bei gesteckter Nvidia-Karte (Asrock Z97 Extreme6, Intel Xeon e3 1246, Geforce GTX750ti):
    [Virtualisierung] Stand der Technik: Nvidia-Grafikkarte an virtuelle Maschine durchreichen mit KVM vfio


    Gruß
    hepi

  • 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


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


    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


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


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


    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

  • Elegantere Lösungen werden gerne angenommen.

    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

    und das dadurch gestartete Python3-Skript (mit python-dbus, python-gi - man müsste nachsehen, wie die entsprechenden ebuilds unter Gentoo heißen - und dem pydbus2vdr-Modul als Abhängigkeiten):
    Das könnte dann in etwa so aussehen:

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • 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

  • So sollte es in der Bash mit dem dbus-monitor klappen:

    Code
    1. FRONTEND=/dev/dvb/adapter0/frontend0
    2. dbus-monitor --system "type='signal',interface='de.tvdr.vdr.status',member='Replaying'" | while read -r line; do
    3. if [ "$line" = "boolean true" ]; then
    4. svdrpsend PLUG dynamite SetIdle "$FRONTEND"
    5. fi
    6. done

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • 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