Suche eine Applikation die ein paar Sekunden braucht um geladen zu sein, um Performance zu erhöhen

[embLin (Gast)]

Hallo an alle,

ich habe hier ein ARM9 SAM9G25 embedded system, wessen Performance ich 
verbessern möchte. Ich nutze Buildroot 2013.10 um meine Linux 2.6.39 
Images zu erstellen.

Es gibt verschiedene Techniken die ich gerne anwenden würde (z.B.: 
Execute from Flash - XIP, oder readahead). Unglücklicherweise fällt mir 
keine passende Applikation ein für diese Anforderungen. Hat jemand eine 
Idee welche App diese Anforderungen erfüllt und bestenfalls noch 
einfach/schnell installier- bzw. anwendbar ist ?

Viele Grüße

[Svenska (Gast)]

Die Idee des Tages wäre "weniger trollen". Danke.

[embLin (Gast)]

Bitte?

[Peter D. (peda)]

embLin schrieb:
> Bitte?

Es gibt hier leider einige Trolle, die nur weil sie Deine Frage nicht 
verstehen, immer gleich rumpöbeln müssen.
Solche Beiträge einfach ignorieren.

Es gibt bestimmt auch deutlich bessere Foren für Linux-Fragen.

[Udo S. (urschmitt)]

Peter Dannegger schrieb:
> Es gibt hier leider einige Trolle, die nur weil sie Deine Frage nicht
> verstehen, immer gleich rumpöbeln müssen.

Also ich bin jetzt kein embedded Libux Kenner, es scheint aber um 
Anwendungen zu gehen, mit denen man schnell Images von Speichermedien in 
den Hauptspeicher bekommt. Klar erklärt ist das aber nicht.

Peter Dannegger schrieb:
> Es gibt bestimmt auch deutlich bessere Foren für Linux-Fragen.

Es gibt bestimmt auch die Möglichkeit sein Vorhaben genauer zu 
erklären...

So zieht er Trolle nur an.

[Boris O. (bohnsorg)]

Berechnungen sind immer schön zu handhaben, der Klassiker sind 
Prüfsummen (md5sum o.ä., schön regelbar über Größe der Datei/ Quelle) 
und Kernel kompilieren (viele Dateien, viel I/O, viel Berechnung). 
Ansonsten dürfen alle Kommandozeilenwerkzeuge benutzt werden, grep, awk, 
sed…

[embLin (Gast)]

Danke an alle konstruktiven Beitragenden.

Meine Frage ist sehr speziell das weiß ich, daher vermute ich dass es 
nicht viel bringt deutlicher zu werden aber ich versuche es einmal:

Ich habe ein Embedded System welches auf einem Linux Kernel basiert und 
mit einer Busybox distro betrieben wird.

Dieses System braucht im Moment ca. 7 s um zu booten (bis zur Anmeldung 
in Busybox). Da genau an dieser Stelle dann erst die Applikation startet 
kommt da noch eine weitere zeit oben drauf (sagen wir + 2 s für die 
Applikation, also insgeasmt 9 s).

Nun gibt es verschiedene Techniken um diese +2 s zu verkürzen im besten 
falls ganz zu eliminieren, z.B.: in dem man vermeidet die Applikation 
bzw. dessen Librarys erst in den RAM zu laden und direkt vom 
flash-Speicher startet (XIP). Oder aber schon die benötigten 
Bibliotheken und Programme während dem Booten bereits in den RAM 
vorlädt, damit sie im Falle der Ausführung sofort anfangen können, 
anstatt erst noch geladen werden zu müssen.

Hier ist nun mein Knackpunkt ein: ich hab keine Applikation für mein 
Embedded System und ich benötige eine die eben diese 2 s (oder mehr) 
benötigt um geladen zu werden und einsatzbereit zu sein.

[embLin (Gast)]

Ich habe es bereits mit dem Buildroot vertriebenen Spiel PrBoom (ein 
Doom Client scheinbar) versucht, weil ich mich erinnern konnte, dass das 
damals schön viel Zeit benötigt hatte auf meiner 100 MHz Maschine. 
Dummerweise erkennt das Programm ob das System über einen Videoausgang 
verfügt oder nicht und eben das fehlt an meinem Gerät. Die einzige 
Zugriffsmöglichkeit ist eigentlich nur eine Serielle Schnittstelle.

[Kein Name (Gast)]

Hast du einen Crosscompiler am laufen? Ein einfaches Programm schreiben 
- einen langen Text als Stringkonstante und eine kleine Schleife, die 
auf den gesammten Text zugreift.

[embLin (Gast)]

na wäre das nicht sowas wie eine Warteschleife? Theoretisch geht es bei 
den genannten Funktionen nur darum, die entsprechenden Bibliotheken und 
Programme vorzuladen - also vermute ich dass, dies keine Auswirkung auf 
Schleifen hat?

[Kein Name (Gast)]

Stimmt eigentlich - einen großen Text laden und viele kleine Libraries 
laden sind nicht das selbe. :-(

[Kein Name (Gast)]

Wenn viele Jar Dateien statt viele Shared Libraries OK sind - die Java 
SE Embedded im Headless Modus.

[Svenska (Gast)]

Hallo,

ich bin für gewöhnlich kein Troll, aber danke trotzdem fürs Lob.

> ich habe hier ein ARM9 SAM9G25 embedded system, wessen Performance ich
> verbessern möchte.
Aber was ist das bitte sonst für eine Nullaussage? "Performance 
verbessern" kann man auch durch eine neue CPU. Das dürfte vermutlich 
sogar die beste Antwort sein.

Wenn es ein halbwegs komplexes realistisches Szenario simulieren will, 
könnte man einen X-Server (geht auch headless mit Xvfb, Xvnc oder so) 
mit Window-Manager und 2-3 kleinen Applets starten. Eventuell ein 
kleines Qt- und ein kleines GTK-Äppchen, um möglichst viele verschiedene 
Libraries geladen zu haben.

Steht als Zielanwendung aber was kleines, monolithisches im Raum, dann 
reicht eine Warteschleife. Optimieren muss man die Startzeit dann an 
anwendungsabhängigen Stellen.

Mir ist vor längerer Zeit mal ein Vortrag "Einschalten, Booten, 
Qt-Anwendung in 1 Sekunde" über den Weg gelaufen, die Folien gibt es 
hier: http://www.slideshare.net/andrewmurraympc/elce-the.

Die Aufgabenstellung ist aber trotzdem unkonkret-nutzlos, außer es 
handelt sich um eine Machbarkeitsstudie.

Gruß,
Svenska

[top (Gast)]

embLin schrieb:
> Es gibt verschiedene Techniken die ich gerne anwenden würde (z.B.:
> Execute from Flash - XIP, oder readahead). Unglücklicherweise fällt mir
> keine passende Applikation ein für diese Anforderungen. Hat jemand eine
> Idee welche App diese Anforderungen erfüllt und bestenfalls noch
> einfach/schnell installier- bzw. anwendbar ist ?

Hier ist ein Startpunkt: 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/ramfs-rootfs-initramfs.txt?id=HEAD

Bau dir zuerst einen Blocktreiber für dein Flash der mmap unterstützt 
und dann schau was dir von o.g. genannten Filesystemen weiterhilft.

[embLin (Gast)]

Aber leider hängt das mit u.U. größerem Aufwand zusammen extra eine 
Applikation selber zu schreiben. Ich bin mir sicher dass es irgendwelche 
open-source Programme gibt, die man mal eben starten kann.

Die Java Maschine könnte womöglich eine Lösung sein, wenn sie denn 
Busybox kompatibel ist, ich schau mir das mal genauer an

[Stefan F. (Gast)]

Sicher gibt es irgendwelche Open-Source Programe, die mehrere Sekunden 
zum Starten brauchen. Zum Beispiel Openoffice. Und wie geht es dann 
weiter? Du wirst wohl kaum das Office umprogrammieren wollen - oder etwa 
doch?

[embLin (Gast)]

Na eben weil ich das nicht will schreibe ich doch hier ins Forum ob 
vielleicht einem eine geeignete App einfällt ;), ich erwarte ja keine 
Wunder. Fragen kostet ja nichts

[Martin H. (marrtn)]

embLin schrieb:
> Die Java Maschine könnte womöglich eine Lösung sein, wenn sie denn
> Busybox kompatibel ist, ich schau mir das mal genauer an

Wie soll denn Java von Busybox abhängen?
Busybox ist eine möglichst embedded-taugliche Implementierung der 
*nix-Shell-Werkzeuge. Ich glaube kaum, dass die Java VM versucht 
irgendwas auf der Shell aufzurufen...

Ansonsten ist Dein Vorhaben wahrscheinlich zum scheitern verurteilt. 
Optimieren kann man (meist) nur an konkreten Problemen. Nachdem Dir 
letzteres fehlt, ist die Wahrscheinlichkeit sehr groß, dass die Dir 
vorschwebende Optimierung an Deinem späteren Anwendungsfall 
vorbeischiesst.
Such Dir doch als allererstes Mal einen konkreten Anwendungsfall, dann 
ergibt sich das Testszenario gerne von alleine...

[Jobst M. (jobstens-de)]

Naja, es benötigt eben seine Zeit, bis die Daten vom Filesystem in den 
Arbeitsspeicher geladen sind. Auch wenn das Flash, welches am selben Bus 
hängt wie das RAM, von der CPU her die Möglichkeit anbietet, direkt 
daraus Code ausführen zu können. Im Dateisystem liegen die Daten nämlich 
vermutlich nicht unbedingt so, wie sie ausgeführt werden müssen. Das ist 
aber nur ein Problem, welches man sogar noch bewältigen könnte. Viel 
komplizierter wird es sein, den Kernel davon zu überzeugen, dies tun zu 
müssen. Gibt es da spezielle Erweiterungen? Sind mir nicht bekannt.

Das einfachste wird vermutlich sein, Dein Spezialprogramm mit in Busybox 
einzukompilieren. Dann ist es beim Rechnerstart automatisch schon 
geladen.


Gruß

Jobst

[enc (Gast)]

Jobst M. schrieb:
> Naja, es benötigt eben seine Zeit, bis die Daten vom Filesystem in den
> Arbeitsspeicher geladen sind. Auch wenn das Flash, welches am selben Bus
> hängt wie das RAM, von der CPU her die Möglichkeit anbietet, direkt
> daraus Code ausführen zu können. Im Dateisystem liegen die Daten nämlich
> vermutlich nicht unbedingt so, wie sie ausgeführt werden müssen. Das ist
> aber nur ein Problem, welches man sogar noch bewältigen könnte. Viel
> komplizierter wird es sein, den Kernel davon zu überzeugen, dies tun zu
> müssen. Gibt es da spezielle Erweiterungen? Sind mir nicht bekannt.

Schon mal was von paging gehört? Kann jedes Unix.

> Das einfachste wird vermutlich sein, Dein Spezialprogramm mit in Busybox
> einzukompilieren. Dann ist es beim Rechnerstart automatisch schon
> geladen.

Nicht unbedingt, warum sollte das Binary komplett geladen werden? Es 
werden nur die Pages geladen die auch benutzt werden.

Wenn das Flash "normal" im Adressraum liegt und der Treiber mmap 
entsprechend unterstützt braucht nix geladen zu werden, lediglich die 
MMU muß entsprechend konfiguriert werden.

Schau dir mal mit strace an wie *.so geladen werden.

[Rolf Magnus (Gast)]

Martin H. schrieb:
> Ansonsten ist Dein Vorhaben wahrscheinlich zum scheitern verurteilt.
> Optimieren kann man (meist) nur an konkreten Problemen. Nachdem Dir
> letzteres fehlt, ist die Wahrscheinlichkeit sehr groß, dass die Dir
> vorschwebende Optimierung an Deinem späteren Anwendungsfall
> vorbeischiesst.

Das denke ich auch. Es gibt ja durchaus unterschiedliche Gründe, warum 
Programm lange zum Starten brauchen. Man braucht das konkrete Programm, 
damit man dort messen kann, wo die Zeit verbraucht wird und wo bei genau 
diesem Programm der effektivste Ansatzpunkt für eine Optimierung ist.

[Ulrich P. (uprinz)]

Es ist schon recht schwer Deine Anfrage zu verstehen. Also erst die 
Kryptografie, dann die Glaskugel:

1) Du hast ein bestehendes System auf einem alten langsamen ARM mit 
einem alten kernel und vermutlich einem alten uboot. Das alt ist dabei 
nicht als Qualitätsmerkmal sondern als zeitliche Feststellung zu sehen.

2) Du verwendest eine komplette vorgefertigte Build-Umgebung, die dir 
Dein Image zusammen zaubert.

3) Du wünschst Dir, dass der Zeitraum zwischen Einschalten des Systems 
und dem Erscheinen von deinem Programm möglichst kurz ist.

4) Du glaubst, dass es eine fertige App gibt, die Dein Problem löst.

Leider geht das nicht. Eine App (ich hasse diesen nichtssagenden 
Verlegenheitsbegriff für alles was man nicht kennt und nicht versteht) 
ist in Deinem Fall wohl eher eine Software, die selbst ja schon auf 
einem fertig gestarteten System laufen muss, um selber aktiv zu werden. 
Sie kann also erst greifen, wenn die ersten 7s plus ihre eigene Ladezeit 
vorüber sind.

Es wird Dir also nichts anderes übrig bleiben, als zu untersuchen, ob 
ein modernerer Kernel und ein moderneres uboot die Startzeit des Systems 
verkürzen könnten.

FLASH ist i.d.R. langsamer als RAM, daher:
Es gibt eine Schere aus CPU Leistung und FLASH Datendurchsatz. Es lohnt 
sich auszurechnen oder experimentell zu messen, ob:
- es schneller ist einen kernel unkomprimiert aus dem Flash ins RAM zu 
kopieren
- es schneller ist einen komprimierten kernel beim laden aus dem Flash 
zu entpacken
- einen linear adressierbaren Flash zu nehmen und den kernel im FLASH zu 
lassen.

Gerade wenn das System als Flash eMMC einsetzt lohnt es sich bei kernel 
2.6.x mal an den mmc treibern zu schrauben. Ich hatte schon Treiber mit 
satten 364kB/s Durchsatz, die nach etwas optimierung der Platine und der 
Konfiguration der beteiligten GPIOs, erweiterrung des Treibers auf 8bit 
Modus und DDR zugriff auf 8MB/s beschleunigten.

Das gilt natürlich auch für das uboot, auch hier kann man mit etwas 
Liebe zum  Detail einiges heraus holen und ein Kernel wird dann statt in 
3s eben in 0.5s auss dem Flash in RAM kopiert.

(Allein, wenn man die uboot Ausgaben minimiert und die Delay Zeit auf 
das minimal nötigste reduziert...)

Und dann der kernel selber...
So eine buildroot von der Stange lädt ja eine Menge Treiber, die man 
selbst vielleicht garnicht braucht. Die kosten ja 2x Zeit, einmal, weil 
sie den Kernel größer machen (Lade-Zeit) und einmal weil sie selber 
initialisiert werden.

Da gibt es so viel zu schrauben... Da muss man sich halt recht tief 
hinein begeben.

Gruß
Ulrich

[embLin (Gast)]

entschuldigt meine verspätete Antwort, ich war leider etwas verhindert.

@enc: danke das war mir gar nicht bewusst, solche Informationen sind 
immer gut zu wissen!

@diejenigen, die die Frage noch nicht verstehen:
Ich suche keine App die mein System schneller macht, sondern ich hier 
habe Methoden vorliegen, die die App schneller booten lassen. 
Dummerweise habe ich aber keine App auf welche ich diese Techniken 
loslassen könnte. (Im eigentlichen versuche ich nur mein ganzes System 
so schnell wie möglich booten zu lassen - um diese oft gestellte (aber 
meiner Ansicht nach eher Problem abschweifenden) Frage nun zu 
beantworten.

Hierbei sollte es sich im idealfall bei der App um 
Initialisierungsprozesse handeln (wie z.B.: Programm laden, Bibliotheken 
einbinden), also weniger um Rechenprozesse oder Warteschleifen, da sonst 
die Funktionen wie readahead  (Programm vor Benutzung in den RAM laden, 
um später bei der Ausführung nicht darauf warten zu müssen) nicht 
greifen werden.

Nochmals danke an die vielen Rückmeldungen!

[embLin (Gast)]

übrigens @urprinz:
das mit dem Geschwindigkeitsboost von ~400 kB/s auf 8 MB/s finde ich 
sehr erstaunlich, das wird mir unabhängig von meiner Frage bestimmt noch 
helfen ;) Danke für den Tipp