4. Achtung: Chrome entleert euren Laptop-Akku schneller als nötig

Achtung: Chrome entleert euren Laptop-Akku schneller als nötig

  • ?

    Es setzt die systemweite Timer-Auflösung von 15,6 ms auf 1 ms.

    http://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/

    0
  • ?

    kthxbye

    0
  • ?

    Das passiert fast immer wenn etwas getimtes wieder gegeben wird - und das bei allen Browsern, bzw. den entsprechend Plugins!

    0
  • ?

    das ist normalerweise nur nötig wenn flash oder ähnliches läuft, aber das passiert auch bei ner leeren startseite schon

    0
  • ?

    Warum sollte das Flash brauchen? ~60 FPS sind doch wirklich genug für everyone.

    0

  • Viel mehr als lol hab ich dazu nicht zu sagen.

    0
  • ?

    hustbaer schrieb:

    Viel mehr als lol hab ich dazu nicht zu sagen.

    und wie soll man dein lol jetzt interpretieren? positiv oder eher negativ?

    0

  • OK, also sag ich doch mehr.

    Es gibt mMn. gute Gründe dafür, dass man möchte dass der System-Timer mit 1ms upgedated wird. Es gibt auch gute Gründe dafür dass man möchte dass z.B. Sleep(7) nicht >= 15~16ms dauert, sondern (meistens, ist ja nicht garantiert) wirklich etwa 7-8ms.

    Beispiel: versuch mal nen Tearing-freien Present im Windowed-Mode mit D3D9 zu machen wenn die Desktop-Composition (die selbst nicht wenig Power frisst) deaktiviert ist. Bzw. auf XP Systemen wo es keine Desktop-Composition gibt. Das bedeutet nämlich du musst Sleep()en so lange es geht, und den Rest dann mit busy-wait warten. Also noch schlimmere Stromverschwendung. Jetzt kannst du dir aussuchen ob du 1-2ms pro Frame mit busy-wait verbringst, oder die gesamte Wartezeit (bei 60 fps verbietet sich bei ~15ms Timer-Frequenz jedes Sleep). Ja, klar, ein Programm könnte im Pause Mode, bzw. wenn eben kein Video läuft zurückgehen auf 15ms. Klingt aber einfacher als es umzusetzen ist.

    Anderes Beispiel: du willst die Ausführungszeit verschiedener Funktionen/Blöcke in deinem Programm messen, und dazu an vielen vielen Stellen im Programm sehr sehr oft die Zeit abfragen. Die billigste Funktion mit der das geht ist GetTickCount. Läuft zig bis hundert mal schneller als alle Alternativen. Damit GetTickCount ne brauchbare Auflösung hat brauchst du aber timeBeginPeriod(1) . Also machst du es, weil es unter Vollast immer noch die billigste Alternative ist.

    Anwendungen die darauf angewiesen sind dass der Scheduler global mit 1ms arbeitet wird es dagegen vermutlich recht wenige geben.

    D.h. es wäre angesagt hier am Scheduler bzw. allgemein der Art & Weise wie das System mit Timer-Interrupts umgeht was zu schrauben, und zwar gröber. Und den Anwendungen dann genau die Dinge zu ermöglichen die sie brauchen. Wenn ein Programm nur schnellere Timer-Updates braucht, dann muss auch nur der Timer 1x pro ms upgedatet werden. Der Scheduler muss deswegen aber nicht 1x pro ms anlaufen und rumschedulen.

    Genau so sollte es möglich sein Sleep() mit <= 1ms Genauigkeit zu ermöglichen, ohne dass dazu gleich global und für einen längeren Zeitraum der Timer-Interrupt beschleunigt werden muss.

    Das OS könnte den Programmen z.B. die Möglichkeit geben bei Sleep einen Hint mitzugeben wie genau es denn sein soll. Und eine Funktion mit der das Programm dem OS generell sagen kann wie genau es seine genauesten Sleeps so braucht.

    ----

    Hier einfach nur mit dem Finger auf die Applikationen zu zeigen und "booh!" zu rufen halte ich für wenig sinnvoll und auch nicht zielführend.
    Das mindeste was ich mir erwarten würde, wäre eine Liste der üblichsten Szenarien die Programmierer dazu veranlassen timeBeginPeriod(1) zu machen, inklusive (praktikablen) Vorschlägen wie man es besser machen kann.

    Auf Artikel in denen einfach nur rumgesudert wird dass die timeBeginPeriod(1) Programme/Programmierer so pöse sind, ohne konkrete Vorschläge wie man es besser machen kann, kann ich mir als Reaktion aber spontan nicht mehr als ein "lol" abringen.

    p.S.:
    Und wenn jemand "It was affected. A lot." schreibt, dann erwarte ich mir dass die Zahlen die darauf folgen grösser als 2.5~5% sind -- die ich nebenbei gesagt schonmal anzweifle, bis ich sie selbst nachgemessen habe. Bzw. es wäre interessant über welches System wir da reden.

    0

  • BTW:
    CatalystControlCenter verwendet anscheinend auch WPF, und läuft immer im Hintergrund mit. Auch dämlich. Vor allem wo ich CCC so eingestellt hab' dass es kein Tray-Icon anzeigt. Nachdem ich jetzt selbst sudere: einfacher Fix: CCC.exe muss nicht permanent als Hintergrund-Prozess mitlaufen. Nichtmal wenn es ein Tray-Icon anzuzeigen gäbe, denn dafür tut es ein klitzekleiner Tray-Icon-Hilfsprozess. Und der braucht dann kein WPF.

    Bzw. noch ein LOOOOL aus dem Artikel

    I don’t have the powercfg output for it but C:\Windows\System32\quartz.dll is another cause of an increased timer frequency. I’m not even sure what Quarts is (Expression Web Designer?) but I know it is sometimes wasting energy.

    #1 Dumpfbacke, kannst quartz nichtmal richtig abtippen
    #2 Dumpfbacke, wenn du schon rumsuderst dann investiere doch die 30 Sekunden dir zu ergoogeln dass die quartz.dll das Zuhause für alle möglichen DirectShow Filter ist. Und DirectShow... nuja..., Video und so, Graph Reference-Clock und so - neeeeeeee, da braucht man sicher keine gute Timer-Auflösung, total bekloppt. 🙄
    Also #3 Dumpfbacke weil du weisst nichtmal von was du redest bist dir aber trotzdem sicher dass das Ding auf jeden Fall Energie verschwendet. Pah. Fatzke.

    (Dass "du" hier ist natürlich auf den Autor des Blog-Beitrags bezogen, nicht auf irgendwen hier im Forum)

    0
  • Mod

    Also ich fand's interessant, dass die gemessenen Zeiten ausgerechnet im Bereich 3.9 bis 4.1 lagen. Mag sein, dass er das wirklich ganz naiv unschuldig so gemessen hat. Aber irgendwie drängte sich mir beim Lesen ein Vergleich mit den Preisen im Supermarkt auf.

    0
  • ?

    Fakt ist das Microsoft den Developern vom Nutzen dieser Funktion abrät.

    0
  • Z

    tickless schrieb:

    Fakt ist das Microsoft den Developern vom Nutzen dieser Funktion abrät.

    Wo?

    0
  • S

    Junge junge...

    timeBeginPeriod sollte nur verwendet werden, wenn es unbedingt notwendig ist. Weil es eben die Performance des Systems und den Energieverbrauch negativ beeinflusst. Warum das so ist, liegt ja auf der Hand.

    Microsoft raet aktiv davon ab das zu missbrauchen. zB:

    http://msdn.microsoft.com/en-us/windows/hardware/gg463266.aspx schrieb:

    If an application must use a high-resolution periodic timer, consider disabling use of the periodic timer and associated functionality when a Power Saver power plan is active or when the system is running on battery power.

    Apple hat deshalb zB in OS X 10.9 Timer Coalescing eingefuehrt.
    http://www.apple.com/osx/preview/advanced-technologies.html

    Das ganze ist auf Desktoprechnern irrelevant, aber auf low tech systemen die immer populaerer werden (subnotebooks, tables, smartphones,...) ist sowas sehr wichtig.

    0
  • ?

    Microsoft spricht von bis zu 25% mehr Verbrauch: http://msdn.microsoft.com/en-us/library/windows/hardware/gg463269.aspx

    0
  • ?

    Sorry, falscher Link. Hier der richtige: http://download.microsoft.com/download/3/0/2/3027D574-C433-412A-A8B6-5E0A75D5B237/Timer-Resolution.docx

    0

  • hustbaer schrieb:

    Es gibt mMn. gute Gründe dafür, dass man möchte dass der System-Timer mit 1ms upgedated wird. Es gibt auch gute Gründe dafür dass man möchte dass z.B. Sleep(7) nicht >= 15~16ms dauert, sondern (meistens, ist ja nicht garantiert) wirklich etwa 7-8ms.

    Dennoch fällt mir kein guter Grund ein, wieso ein Webbrowser dies tun sollte, wenn ich grad nur meine Einkaufsliste angucken will...

    hustbaer schrieb:

    Beispiel: versuch mal nen Tearing-freien Present im Windowed-Mode mit D3D9 zu machen wenn die Desktop-Composition (die selbst nicht wenig Power frisst) deaktiviert ist. Bzw. auf XP Systemen wo es keine Desktop-Composition gibt. Das bedeutet nämlich du musst Sleep()en so lange es geht, und den Rest dann mit busy-wait warten. Also noch schlimmere Stromverschwendung. Jetzt kannst du dir aussuchen ob du 1-2ms pro Frame mit busy-wait verbringst, oder die gesamte Wartezeit (bei 60 fps verbietet sich bei ~15ms Timer-Frequenz jedes Sleep). Ja, klar, ein Programm könnte im Pause Mode, bzw. wenn eben kein Video läuft zurückgehen auf 15ms. Klingt aber einfacher als es umzusetzen ist.

    Ja, das Problem kenn ich nur zu gut. Inwiefern das für das Anzeigen statischer HTML Seiten relevant ist, ist mir allerdings unklar. Abgesehen davon, sollte man sich da imo erstmal gewisse andere Fragen stellen. Wie z.B. wieso die Composition aus sein muss, wieso es Windowed sein muss und natürlich vor allem, wieso ordentliche Lösungen wie z.B. http://msdn.microsoft.com/en-us/library/windows/desktop/bb174559.aspx nicht in Frage kommen.

    hustbaer schrieb:

    Anderes Beispiel: du willst die Ausführungszeit verschiedener Funktionen/Blöcke in deinem Programm messen, und dazu an vielen vielen Stellen im Programm sehr sehr oft die Zeit abfragen. Die billigste Funktion mit der das geht ist GetTickCount. Läuft zig bis hundert mal schneller als alle Alternativen. Damit GetTickCount ne brauchbare Auflösung hat brauchst du aber timeBeginPeriod(1) . Also machst du es, weil es unter Vollast immer noch die billigste Alternative ist.

    Also ich weiß nicht; wenn du mich fragst, ist das allerletzte, was ich gerne machen möchte, wenn ich meinen Code profilen will, die Messergebnisse zu verfälschen, indem ich meinem System schnell mal 16x so viele Context Switches pro Sekunde spendiere als nötig. Viel sinnvoller wär da wohl eher z.B. das. Außerdem ist das auch wieder kein für den Produktiveinsatz beim Endkunden relevanter Anwendungsfall.

    hustbaer schrieb:

    Hier einfach nur mit dem Finger auf die Applikationen zu zeigen und "booh!" zu rufen halte ich für wenig sinnvoll und auch nicht zielführend.
    Das mindeste was ich mir erwarten würde, wäre eine Liste der üblichsten Szenarien die Programmierer dazu veranlassen timeBeginPeriod(1) zu machen, inklusive (praktikablen) Vorschlägen wie man es besser machen kann.

    In vielen Fällen wäre wohl z.B. das die bessere Lösung: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684247.aspx

    hustbaer schrieb:

    Auf Artikel in denen einfach nur rumgesudert wird dass die timeBeginPeriod(1) Programme/Programmierer so pöse sind, ohne konkrete Vorschläge wie man es besser machen kann, kann ich mir als Reaktion aber spontan nicht mehr als ein "lol" abringen.

    Konkreter Vorschlag um es im konkreten Fall besser zu machen: Kein timeBeginPeriod() verwenden wenn nicht notwendig. Ich bin selbst überzeugter Chrome User, aber ein Webbrowser hat, zumindest ohne wirklichen Grund, verdammt nochmal die Finger von meinen Heartbeat zu lassen...

    0
  • ?

    Komischerweise kommt Linux doch auch mit einer festen Tick-Rate aus, die sich nicht zur Laufzeit ändern lässt. Und kann auch Multimedia ganz gut.

    0

  • dot schrieb:

    hustbaer schrieb:

    Es gibt mMn. gute Gründe dafür, dass man möchte dass der System-Timer mit 1ms upgedated wird. Es gibt auch gute Gründe dafür dass man möchte dass z.B. Sleep(7) nicht >= 15~16ms dauert, sondern (meistens, ist ja nicht garantiert) wirklich etwa 7-8ms.

    Dennoch fällt mir kein guter Grund ein, wieso ein Webbrowser dies tun sollte, wenn ich grad nur meine Einkaufsliste angucken will...

    Weil die Leute alle rummoppeln wenn das Scrollen nicht flüssig läuft. Bzw. irgendwelche Plugins, die zu doof sind selbst timeBeginPeriod() zu machen.

    dot schrieb:

    hustbaer schrieb:

    Beispiel: versuch mal nen Tearing-freien Present im Windowed-Mode mit D3D9 zu machen wenn die Desktop-Composition (die selbst nicht wenig Power frisst) deaktiviert ist. Bzw. auf XP Systemen wo es keine Desktop-Composition gibt. Das bedeutet nämlich du musst Sleep()en so lange es geht, und den Rest dann mit busy-wait warten. Also noch schlimmere Stromverschwendung. Jetzt kannst du dir aussuchen ob du 1-2ms pro Frame mit busy-wait verbringst, oder die gesamte Wartezeit (bei 60 fps verbietet sich bei ~15ms Timer-Frequenz jedes Sleep). Ja, klar, ein Programm könnte im Pause Mode, bzw. wenn eben kein Video läuft zurückgehen auf 15ms. Klingt aber einfacher als es umzusetzen ist.

    Ja, das Problem kenn ich nur zu gut. Inwiefern das für das Anzeigen statischer HTML Seiten relevant ist, ist mir allerdings unklar. Abgesehen davon, sollte man sich da imo erstmal gewisse andere Fragen stellen. Wie z.B. wieso die Composition aus sein muss, wieso es Windowed sein muss und natürlich vor allem, wieso ordentliche Lösungen wie z.B. http://msdn.microsoft.com/en-us/library/windows/desktop/bb174559.aspx nicht in Frage kommen.

    Siehe oben, Scrollen. Und die saubere Lösung kommt nicht in Frage, weil es halt noch andere Plattformen als Windows Phone 8 gibt.

    dot schrieb:

    hustbaer schrieb:

    Anderes Beispiel: du willst die Ausführungszeit verschiedener Funktionen/Blöcke in deinem Programm messen, und dazu an vielen vielen Stellen im Programm sehr sehr oft die Zeit abfragen. Die billigste Funktion mit der das geht ist GetTickCount. Läuft zig bis hundert mal schneller als alle Alternativen. Damit GetTickCount ne brauchbare Auflösung hat brauchst du aber timeBeginPeriod(1) . Also machst du es, weil es unter Vollast immer noch die billigste Alternative ist.

    Also ich weiß nicht; wenn du mich fragst, ist das allerletzte, was ich gerne machen möchte, wenn ich meinen Code profilen will, die Messergebnisse zu verfälschen, indem ich meinem System schnell mal 16x so viele Context Switches pro Sekunde spendiere als nötig. Viel sinnvoller wär da wohl eher z.B. das. Außerdem ist das auch wieder kein für den Produktiveinsatz beim Endkunden relevanter Anwendungsfall.

    Also die Beschreibung liest sich danach als ob es mit RDTSC implementiert wäre. Was schonmal nicht ganz doof wäre. Dummerweise komm ich damit auf keine Zeit, sondern nur auf relativ zueinander vergleichbaren Werten, die halt die verbratenen Zyklen angeben.
    Und woher willst du sagen dass es kein für den Einsatz beim Kunden relevanter Fall ist?

    dot schrieb:

    hustbaer schrieb:

    Hier einfach nur mit dem Finger auf die Applikationen zu zeigen und "booh!" zu rufen halte ich für wenig sinnvoll und auch nicht zielführend.
    Das mindeste was ich mir erwarten würde, wäre eine Liste der üblichsten Szenarien die Programmierer dazu veranlassen timeBeginPeriod(1) zu machen, inklusive (praktikablen) Vorschlägen wie man es besser machen kann.

    In vielen Fällen wäre wohl z.B. das die bessere Lösung: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684247.aspx

    Hat mit dem was ich geschrieben habe nix zu tun. Damit bekomm ich weder genauere Zeitmessung noch genauere Sleeps.

    dot schrieb:

    hustbaer schrieb:

    Auf Artikel in denen einfach nur rumgesudert wird dass die timeBeginPeriod(1) Programme/Programmierer so pöse sind, ohne konkrete Vorschläge wie man es besser machen kann, kann ich mir als Reaktion aber spontan nicht mehr als ein "lol" abringen.

    Konkreter Vorschlag um es im konkreten Fall besser zu machen: Kein timeBeginPeriod() verwenden wenn nicht notwendig. Ich bin selbst überzeugter Chrome User, aber ein Webbrowser hat, zumindest ohne wirklichen Grund, verdammt nochmal die Finger von meinen Heartbeat zu lassen...

    dot's Herz schlägt mit Windows 🤡
    Ne, ich weiss schon was du meinst, bin ja nicht doof 😃

    Ja, OK. Sollte. Blub. Ist es ein QI Problem? Vermutlich ja. Gibt es meistens bessere Lösungen? Vermutlich auch ja. Gibt es in quasi jeder Software wichtigere Probleme? Darfst du selbst beantworten.

    Es darf ja gerne jeder schreiben dass das nicht optimal ist, und geändert werden sollte. Aber so zu tun als ob das jetzt voll wichtig wäre, und blah, Drama Queen, MS voll pöse und Google voll pöse und ... also ne.

    0

  • mint schrieb:

    Komischerweise kommt Linux doch auch mit einer festen Tick-Rate aus, die sich nicht zur Laufzeit ändern lässt. Und kann auch Multimedia ganz gut.

    Ich vermute mal: weil dort die Timer bzw. die kürzeste von sleep() unterstützte Zeit nicht an den System-Heartbeat gekoppelt ist. Was ich auch für Windows vorschlagen würde.

    0

  • Ach, nochwas: wieso hat schon ein Pentium 60 mit Win95/Win98 nen Heartbeat von 1ms geschafft, und nebenher noch Zeit gehabt Programme laufen zu lassen ... aber auf aktuellen Systemen kostet es immer noch 2,5~5% Leistung? ... öööööööh?
    Does not compute.

    (Mir ist schon klar dass der Vergleich nicht ganz fair ist, weil auf modernen Systemen ca. 100x (übertrieben) mehr im Hintergrund läuft als auf nem nackten Win95. Nur haben moderne Systeme auch die 100-fache (untertrieben) Rechenleistung...)

    0
Anmelden zum Antworten