Quantifying Application Performance for Adaptive Power Management Andreas Weißel Lehrstuhl für Informatik 4 Verteilte Systeme und Betriebssysteme Friedrich-Alexander Universität Erlangen-Nürnberg weissel@cs.fau.de Frank Bellosa System Architecture Group Universität Karlsruhe bellosa@ira.uka.de 1
Motivation Mobile, batteriebetriebene Geräte Energieverbrauch bestimmt Betriebsdauer Energieverbrauch von Systemkomponenten Energiesparmodi (z.b. Laufwerksmotor einer Festplatte anhalten) - zusätzliche Verzögerung, sobald auf das Gerät zugegriffen wird reduzierte Arbeitsgeschwindigkeit (z.b. Anpassung der Prozessortaktrate) Andreas Weißel (weissel@cs.fau.de), Frank Bellosa (bellosa@ira.uka.de) 2
Motivation Auswirkungen auf die Performance? Anwendungsgeschwindigkeit, Warte-/Antwortzeit, Dienstgüte, Durchsatz... abhängig von den Systemkomponenten und deren Betriebsmodi abhängig vom Typ der Anwendung und der spezifischen Operation Adaptive Energiesparverfahren wünschenswert, die die unterschiedlichen Eigenschaften von Anwendungen berücksichtigen Abwägen zwischen Energieeinsparungen und Performance Andreas Weißel (weissel@cs.fau.de), Frank Bellosa (bellosa@ira.uka.de) 3
Ziel Bereitstellung von Betriebssystemdiensten zur Überwachung der Performance von interaktiven Anwendungen zur Laufzeit Feedback über die Auswirkungen verschiedener Energiesparmodi auf die Performance Schwerpunkt liegt auf der Infrastruktur/den Diensten, nicht auf den Energiesparverfahren (policies) Betriebssystem als Mittler kennt Anwendungen und ihre Eigenschaften verwaltet die Betriebsmittel (Betriebsmodi der Systemkomponenten) Andreas Weißel (weissel@cs.fau.de), Frank Bellosa (bellosa@ira.uka.de) 4
Überblick Eigenschaften der Energiesparmodi verschiedener Systemkomponenten Messung der Performance interaktiver Anwendungen Implementierung Ergebnisse Zusammenfassung Andreas Weißel (weissel@cs.fau.de), Frank Bellosa (bellosa@ira.uka.de) 5
Energiesparmodi: WLAN-Interface hoher Stromverbrauch im Idle-Modus (> 1W) Empfangen von Paketen im Idle-Modus Andreas Weißel (weissel@cs.fau.de), Frank Bellosa (bellosa@ira.uka.de) 6
Energiesparmodi: WLAN-Interface hoher Stromverbrauch im Idle-Modus (> 1W) Energiesparmodus mit niedriger Leistungsaufnahme aber: kein Empfang von Paketen möglich! periodische Synchronisation mit der Basisstation: Beacons Empfangen von Paketen im Idle-Modus periodische Synchronisation durch Beacons Andreas Weißel (weissel@cs.fau.de), Frank Bellosa (bellosa@ira.uka.de) 7
Energiesparmodi: WLAN-Interface 802.11 WLAN Standard Beacon-Intervall Beacon Andreas Weißel (weissel@cs.fau.de), Frank Bellosa (bellosa@ira.uka.de) 8
Energiesparmodi: WLAN-Interface 802.11 WLAN Standard Beacon-Intervall Beacon Nachricht Andreas Weißel (weissel@cs.fau.de), Frank Bellosa (bellosa@ira.uka.de) 9
Energiesparmodi: WLAN-Interface 802.11 WLAN Standard Beacon-Intervall Beacon Nachricht poll Andreas Weißel (weissel@cs.fau.de), Frank Bellosa (bellosa@ira.uka.de) 10
Energiesparmodi: WLAN-Interface 802.11 WLAN Standard Verzögerung Beacon-Intervall Beacon Nachricht poll Andreas Weißel (weissel@cs.fau.de), Frank Bellosa (bellosa@ira.uka.de) 11
Energiesparmodi: WLAN-Interface Verzögerungen beim Empfangen von Netzwerkpaketen durchschnittliche Wartezeit: (Beacon-Intervall / 2) extreme Verzögerung bei RPC-basierten Anwendungen (z.b. NFS) nur ein Fernaufruf kann pro Beacon-Intervall durchgeführt werden kein Effekt bei anderen Anwendungen Multimediaplayer (Daten werden gepuffert) Andreas Weißel (weissel@cs.fau.de), Frank Bellosa (bellosa@ira.uka.de) 12
Energiesparmodi: Prozessor Einsparungen durch Taktfrequenzanpassung Stromverbrauch steigt linear mit der Taktfrequenz höhere Einsparungen bei Anpassung der Versorgungsspannung Leistungsaufnahme proportional zum Quadrat der Spannung Geschwindigkeitsverlust bei reduzierter Taktrate abhängig von Zahl der Hauptspeicherzugriffe Wartezyklen beim Zugriff auf Daten in den Speichermodulen Andreas Weißel (weissel@cs.fau.de), Frank Bellosa (bellosa@ira.uka.de) 13
Performance-Messung Was versteht man unter Performance? interaktive Anwendungen: Antwort-, Reaktionszeit Unterscheidung zwischen wait time und think time [Seltzer '96] wait time = Zeit, die die Anwendung benötigt, um eine Benutzereingabe zu verarbeiten (z.b. Mausklick, Tastendruck) think time = Der Benutzer wartet nicht auf eine Reaktion des Systems Andreas Weißel (weissel@cs.fau.de), Frank Bellosa (bellosa@ira.uka.de) 14
Bewertung der Performance Welche Wartezeit ist noch vertretbar für welche Anwendung? qualitative Bewertung schwierig Vergleich mit Wahrnehmungsschwelle (Vertigo, OSDI'02) 50 100ms viele Anwendungen mit wesentlich längeren Wartezeiten - Web browser (ipaq): Seite laden: 0.5 5s, Inhalt um eine Zeile scrollen: 160ms Quantitative Analyse Bestimmung der Wartezeiten und deren Veränderung unter verschiedenen Energiesparmodi Erkennen von Korrelationen & Abhängigkeiten zwischen Energiesparmodi verschiedener Systemkomponenten Andreas Weißel (weissel@cs.fau.de), Frank Bellosa (bellosa@ira.uka.de) 15
Implementierung Anwendungen können nicht immer auf einzelne Prozesse abgebildet werden Betriebssystemabstraktion Resource Containers (OSDI '99) Prozesse werden dynamisch an Resource Container gebunden mehrere Prozesse bilden eine Anwendung Web-Browser/iPAQ: Prozess 1 verarbeitet Benutzereingaben, Prozess 2 verwaltet Zwischenspeicher Prozesse als Dienstgeber / Dienstnehmer X-Server, Sound-Server werden von verschiedenen Anwendungen in Anspruch genommen Serverprozess wird temporär an den Container des Client gebunden Kommunikation zwischen Prozessen beobachten (Pipes, Sockets) Andreas Weißel (weissel@cs.fau.de), Frank Bellosa (bellosa@ira.uka.de) 16
Implementierung Prozesswechsel überwachen (schedule) ändert sich auch der aktuelle Resource Container (Anwendung)? Wartezeiten können Ein-/Ausgabeoperationen enthalten synchrone Lesezugriffe auf die Festplatte: (do_rw_disk) Netzwerk-Kommunikation: auf Antwort warten, falls eine Nachricht verschickt wurde (tcp_sendmsg, tcp_rcvmsg) kurze CPU Idle-Phasen ignorieren sehr kurze aktive Phasen (< 1 ms) ignorieren Resource Container inaktiv für mehr als 250 ms: think time Andreas Weißel (weissel@cs.fau.de), Frank Bellosa (bellosa@ira.uka.de) 17
Implementierung Ermittlung der Wartezeiten unter verschiedenen Betriebsmodi In Ringpuffer sichern periodische Berechnung der durchschnittlichen Wartezeiten Systemcall zur Abfrage der Wartezeiten eines Resource Containers Unterscheidung von Wartezeiten mit Netzwerkkommunikation, Festplattenzugriffen und ohne Ein-/Ausgabeoperationen Andreas Weißel (weissel@cs.fau.de), Frank Bellosa (bellosa@ira.uka.de) 18
Ergebnisse ipaq 3970 CPU: Intel PXA 250, 200/300/400 MHz WLAN-Interface: Cisco Aironet Festplatte: Hitachi Microdrive Linux-Distribution Familiar Graphische Oberfläche: GPE (X server, GTK+) Linux 2.4.19/ARM Andreas Weißel (weissel@cs.fau.de), Frank Bellosa (bellosa@ira.uka.de) 19
Ergebnisse: CPU Taktfrequenz Wartezeiten verschiedener interaktiver Anwendungen Anwendung 200 MHz 300 MHz 400 MHz dillo (web) 556 ms 459 ms 454 ms dillo (scroll) 270 ms 252 ms 244 ms minimo (web) 2.08 s 1.78 s 1.59 s ssh 7.61 ms 7.51 ms 6.98 ms sketch 51.5 ms 48.6 ms 48.5 ms gallery (display) 376 ms 331 ms 303 ms gallery (zoom) 377 ms 291 ms 260 ms Andreas Weißel (weissel@cs.fau.de), Frank Bellosa (bellosa@ira.uka.de) 20
Ergebnisse: CPU Taktfrequenz Wartezeiten verschiedener interaktiver Anwendungen Anwendung 200 MHz 300 MHz 400 MHz dillo (web) 556 ms 459 ms 454 ms dillo (scroll) 270 ms 252 ms 244 ms minimo (web) 2.08 s 1.78 s 1.59 s ssh 7.61 ms 7.51 ms 6.98 ms sketch 51.5 ms 48.6 ms 48.5 ms gallery (display) 376 ms 331 ms 303 ms gallery (zoom) 377 ms 291 ms 260 ms Geschwindigkeitseinbußen zwischen - weniger als 1% (ssh, 300 200 MHz; sketch, 400 300 MHz) - und 45% (gallery (zoom), 400 200 MHz) Andreas Weißel (weissel@cs.fau.de), Frank Bellosa (bellosa@ira.uka.de) 21
Ergebnisse: WLAN Energiesparmodus 802.11 Power Management nicht aktiv Anwendung 200 MHz 300 MHz 400 MHz dillo 556 ms 495 ms 454 ms minimo 2.08 s 1.78 s 1.59 s ssh 7.6 ms 7.5 ms 7.0 ms 100ms Beacon-Intervall Anwendung 200 MHz 300 MHz 400 MHz dillo 845 ms 831 ms 821 ms minimo 2.03 s 1.76 s 1.65 s ssh 71 ms Andreas Weißel (weissel@cs.fau.de), Frank Bellosa (bellosa@ira.uka.de) 22
Ergebnisse: WLAN Energiesparmodus 802.11 Power Management nicht aktiv Anwendung 200 MHz 300 MHz 400 MHz dillo 556 ms 495 ms 454 ms minimo 2.08 s 1.78 s 1.59 s ssh 7.6 ms 7.5 ms 7.0 ms 100ms Beacon-Intervall Anwendung 200 MHz 300 MHz 400 MHz dillo 845 ms 831 ms 821 ms minimo 2.03 s 1.76 s 1.65 s ssh 71 ms Andreas Weißel (weissel@cs.fau.de), Frank Bellosa (bellosa@ira.uka.de) 23
Ergebnisse: WLAN Energiesparmodus 802.11 Power Management nicht aktiv Anwendung 200 MHz 300 MHz 400 MHz dillo 556 ms 495 ms 454 ms minimo 2.08 s 1.78 s 1.59 s ssh 7.6 ms 7.5 ms 7.0 ms 100ms Beacon-Intervall Anwendung 200 MHz 300 MHz 400 MHz dillo 845 ms 831 ms 821 ms minimo 2.03 s 1.76 s 1.65 s ssh 71 ms Andreas Weißel (weissel@cs.fau.de), Frank Bellosa (bellosa@ira.uka.de) 24
Zusammenfassung Betriebssystemdienste für adaptive Energieverwaltung Messung der Performance interaktiver Anwendungen Ermittlung der durchschnittlichen Wartezeiten für verschiedene Energiesparmodi Erkennen von Abhängigkeiten zwischen den Betriebsmodi verschiedener Systemkomponenten Andreas Weißel (weissel@cs.fau.de), Frank Bellosa (bellosa@ira.uka.de) 25