Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung | Nächste Überarbeitung Beide Seiten der Revision | ||
|
forschung:projekte:rtandroid [2015/02/10 15:49] thoennessen |
forschung:projekte:rtandroid [2015/02/12 11:34] thoennessen |
||
|---|---|---|---|
| Zeile 22: | Zeile 22: | ||
| In der Originaldistribution von Android wird der Lebenszyklus einer Applikationskomponente typischerweise von ihrer Sichtbarkeit bzw. Interaktionsmöglichkeiten mit dem Benutzer beeinflusst. Sobald eine App vollständig in den Hintergrund gerät, verliert sie aus der Sicht des Systems an Wichtigkeit für den Benutzer und kann pausiert oder gar terminiert werden. In RTAndroid hingegen, können laufende Echtzeitapplikationen unabhängig von ihrer Sichtbarkeit grundsätzlich nicht vom System negativ beeinflusst werden. Während Hintergrundprozesse in Android auch zugunsten der längeren Akkulaufzeit unterbrochen werden können, agiert RTAndroid als eine zuverlässige Ausführungsplattform für Langzeitoperationen. Ein vorhersagbares Laufzeitverhalten wird selbst bei ausgeschaltetem Bildschirm garantiert, während in einem gewöhnlichen Android dabei der Ruhemodus aktiviert wird und die einzelnen Prozessoren herunterfahren oder –getaktet werden.\\ | In der Originaldistribution von Android wird der Lebenszyklus einer Applikationskomponente typischerweise von ihrer Sichtbarkeit bzw. Interaktionsmöglichkeiten mit dem Benutzer beeinflusst. Sobald eine App vollständig in den Hintergrund gerät, verliert sie aus der Sicht des Systems an Wichtigkeit für den Benutzer und kann pausiert oder gar terminiert werden. In RTAndroid hingegen, können laufende Echtzeitapplikationen unabhängig von ihrer Sichtbarkeit grundsätzlich nicht vom System negativ beeinflusst werden. Während Hintergrundprozesse in Android auch zugunsten der längeren Akkulaufzeit unterbrochen werden können, agiert RTAndroid als eine zuverlässige Ausführungsplattform für Langzeitoperationen. Ein vorhersagbares Laufzeitverhalten wird selbst bei ausgeschaltetem Bildschirm garantiert, während in einem gewöhnlichen Android dabei der Ruhemodus aktiviert wird und die einzelnen Prozessoren herunterfahren oder –getaktet werden.\\ | ||
| \\ | \\ | ||
| - | {{:forschung:projekte:2015-02-09_evaluation_02.png?300 |}} | + | {{:forschung:projekte:evaluationlatenz.png?300 |}} |
| Das Zusammenspiel der hier beschriebenen Techniken ermöglicht vorhersagbare Reaktionszeiten und reduziert auftretende Latenzen – d.h. Differenzen zwischen dem geplanten und dem tatsächlichen Ausführungszeitpunkt – von mehreren Sekunden auf unter eine Millisekunde. Eine Veranschaulichung der Reaktionszeiten ist in der nebenstehenden Grafik zu finden. Über 1000 Ausführungsiterationen wurde die Ausführungsverzögerung einer Testapplikation in µs gemessen. Im Diagramm gegenübergestellt sind in hellblau die Latenzen einer Nicht-Echtzeit Anwendung und in dunkelblau jene einer Echtzeitanwendung. Die Analyse der Messergebnisse liefert einen Worst Case der Latenzen von 1255 µs bzw. 61 µs. \\ \\ | Das Zusammenspiel der hier beschriebenen Techniken ermöglicht vorhersagbare Reaktionszeiten und reduziert auftretende Latenzen – d.h. Differenzen zwischen dem geplanten und dem tatsächlichen Ausführungszeitpunkt – von mehreren Sekunden auf unter eine Millisekunde. Eine Veranschaulichung der Reaktionszeiten ist in der nebenstehenden Grafik zu finden. Über 1000 Ausführungsiterationen wurde die Ausführungsverzögerung einer Testapplikation in µs gemessen. Im Diagramm gegenübergestellt sind in hellblau die Latenzen einer Nicht-Echtzeit Anwendung und in dunkelblau jene einer Echtzeitanwendung. Die Analyse der Messergebnisse liefert einen Worst Case der Latenzen von 1255 µs bzw. 61 µs. \\ \\ | ||
| - | {{ :forschung:projekte:2015-02-09_evaluation_01.png?300|}} | + | {{ :forschung:projekte:evaluationberechnungszeit.png?300|}} |
| Eine weitergehende Evaluation ist in dem untenstehenden Diagramm zu finden. Dort aufgezeichnet ist die Berechnungszeit eine Testapplikation über eine Testausführung von 1000 Iterationen, ähnlich wie im vorangehenden Test. Hier wurde jedoch nicht die Ausführungslatenz gemessen, sondern die Berechenungsdauer einer komplexen Rechenoperation. Die in hellblau aufgezeichneten Messwerte belegen eine durchschnittliche Berechnungsdauer von 12939 µs für den Testlauf auf einer handelsüblichen Android Distribution. Dem gegenüber steht eine Berechnungsdauer von durchschnittlich 1745 µs für den Testlauf auf RTAndroid. Des Weiteren ist eine deutlich geringere Standardabweichung in den Messwerten von RTAndroid zu erkennen, die Berechnungszeiten sind somit deutlich vorhersagbarer. \\ \\ | Eine weitergehende Evaluation ist in dem untenstehenden Diagramm zu finden. Dort aufgezeichnet ist die Berechnungszeit eine Testapplikation über eine Testausführung von 1000 Iterationen, ähnlich wie im vorangehenden Test. Hier wurde jedoch nicht die Ausführungslatenz gemessen, sondern die Berechenungsdauer einer komplexen Rechenoperation. Die in hellblau aufgezeichneten Messwerte belegen eine durchschnittliche Berechnungsdauer von 12939 µs für den Testlauf auf einer handelsüblichen Android Distribution. Dem gegenüber steht eine Berechnungsdauer von durchschnittlich 1745 µs für den Testlauf auf RTAndroid. Des Weiteren ist eine deutlich geringere Standardabweichung in den Messwerten von RTAndroid zu erkennen, die Berechnungszeiten sind somit deutlich vorhersagbarer. \\ \\ | ||