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
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.
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.
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…
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.
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.
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.
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?
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
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.
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
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?
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
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...
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
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.
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.
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
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!
ü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
