SwiftBoot, la société suisse qui avait déjà fait parler d'elle avec un boot en moins de cinq seconde d'un noyau + affichage caméra, refait parler d'elle.
Là il s'agit de booter en une seule seconde, sur uneRenesas MS7724, avec une interface complète (Qt), toujours pour de la vidéo. Et cette fois ci, ils prennent soin de détailler le process, et de donner les modifications... tout en insistant sur le fait qu'aucun blob ou brique non libre n'a été ajoutée d'une part, et d'autre part qu'il ne s'agit d'une astuce par artifice (de type suspend). Enfin ils se réjouissent par avance, espèrant bénéficier d'un article chez Free Electrons.
La démo est là (flash inside, pas trouvé de lien direct)
http://www.swiftboot.com/swiftBoot/Demos.html
Quant au code source de leurs modifs, et la doc précise, je cherche toujours... Ce qui est sûr c'est qu'une telle rapidité (et stabilité, ils n'y vont pas mollo mollo avec l'alimentation) voit de suite une place intéressante dans un tableau de bord.
Mais bon, encore faudrait il pouvoir trouver leur doc... au moins... là, y a des paroles, une vidéo, mais je trouve rien d'autre. Tout ceci est très alléchant, mais entre le ramage et le plumage... je préfère le fromage. Haa si y a quant même un peu de doc \o/ un slideshow avec tellement de pub autour qu'on oublie le côté powerpoint du truc. http://www.slideshare.net/andrewmurraympc/elce-the
Bons croissants, et bon café à toutes et tous :-)
Journal boot en une seule seconde
14
jan.
2011
# oubli
Posté par bubar🦥 (site web personnel) . Évalué à 4.
[^] # Re: oubli
Posté par bubar🦥 (site web personnel) . Évalué à 3.
(pas 28, sorry)
[^] # Re: oubli
Posté par Le Pnume . Évalué à 10.
[^] # Re: oubli
Posté par scullder . Évalué à 4.
[^] # Re: oubli
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: oubli
Posté par bubar🦥 (site web personnel) . Évalué à 5.
[^] # Re: oubli
Posté par Frédéric COIFFIER . Évalué à 10.
Ils ont également retiré les temporisations dans l'initialisation des drivers. Bien souvent les temporisations ont été insérées pour supporter les variabilités des matériels. En les retirant, on augmente sensiblement le risque que le périphérique ne fonctionne pas de temps en temps (et je doute que ce risque soit facilement quantifiable).
Et puis, ils ont des outils pour optimiser l'organisation de la flash en se basant sur l'ordre d'éxecution de l'application.
Bref, à la fin, ils ont un "OS" à usage unique, bien spécifique mais assez loin de la souplesse et de la généricité d'un Linux standard. C'est de l'embarqué et ça a un coût de développement non négligeable.
[^] # Re: oubli
Posté par claudex . Évalué à 3.
Ou alors, cela introduit des bugs dans certains cas (qui ne les concernes peut-être pas).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: oubli
Posté par yellowiscool . Évalué à 2.
La moindre des choses, ce serait que cela passe les tests unitaires (si il y en a).
Envoyé depuis mon lapin.
[^] # Re: oubli
Posté par monde_de_merde . Évalué à 10.
C'est évidement pas généralisable pour du desktop, mais la démarche est intéressante et l'on pourrait sans doute en tirer 2 ou 3 bricoles (utilisation d'async, du "defered loading" etc...). Après je doute que ce ne soit pas déjà étudié et/ou mis en place par exemple dans les Ubuntu, Fedora et compagnie.
[^] # Re: oubli
Posté par reno . Évalué à 6.
J'ai même une preuve que c'est possible avec un OS générique: sous BeOS les applications se chargeaient très rapidement, je m'en souviens d'autant mieux que l'innovation sur les OS concurrents à la même époque c'était le *splashscreen*, beurk!
[^] # Re: oubli
Posté par Psychofox (Mastodon) . Évalué à 2.
C'est ce que j'ai fais sur le laptop de ma compagne. Je n'ai pas chronométré mais le temps de boot est vraiment rapide, je le qualifierai même de quasi instantané (en gros on a pas le temps de contempler l'écran de démarrage), quelque soit l'OS (oui même le sale).
# Jusqu'où... et pourquoi
Posté par lolop (site web personnel) . Évalué à 3.
Je peux comprendre qu'on veuille améliorer le temps de démarrage, perso si ça met moins de 2 minutes pour une station de travail ça me suffit.
J'ai plus de mal à voir l'intérêt de pouvoir démarrer si vite, étant donné qu'on a des techniques de mise en veille qui permettent en plus de revenir dans un état de travail tout prêt - les applis nécessaires lancées, les données sur lesquelles on bosse déjà chargées.
Éventuellement l'économie d'énergie de l'extinction complète par rapport à la veille...
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Jusqu'où... et pourquoi
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
"La première sécurité est la liberté"
[^] # Re: Jusqu'où... et pourquoi
Posté par plop (site web personnel) . Évalué à 3.
[^] # Re: Jusqu'où... et pourquoi
Posté par scullder . Évalué à 2.
J'ai qu'un disque dur 5400 rpm en sata 2 qui transfère à plus de 80Mo/s en séquentiel selon hdparm -t.
[^] # Re: Jusqu'où... et pourquoi
Posté par Juke (site web personnel) . Évalué à 2.
/dev/sdb1:
Timing cached reads: 9910 MB in 2.00 seconds = 4965.76 MB/sec
Timing buffered disk reads: 38 MB in 3.11 seconds = 12.24 MB/sec
une idée d'où ça peut venir ?
[^] # Re: Jusqu'où... et pourquoi
Posté par scullder . Évalué à 1.
Au grand hasard, un mauvais mode dma. Regarde avec la commande :
hdparm -i /dev/sdb
Mais normalement c'est bien géré pour utiliser le mode optimal, j'ai pas touché à ça depuis des années.
J'ai de meilleures perf que toi avec une clé usb.
[^] # Re: Jusqu'où... et pourquoi
Posté par Juke (site web personnel) . Évalué à 2.
/dev/sda:
Timing cached reads: 9888 MB in 2.00 seconds = 4954.98 MB/sec
Timing buffered disk reads: 364 MB in 3.00 seconds = 121.19 MB/sec
[^] # Re: Jusqu'où... et pourquoi
Posté par DLFP est mort . Évalué à 2.
Sinon la technique c'est que le contenu de la RAM soit compressé sur le disque dur, pour qu'il y ait moins de données à lire et écrire.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Jusqu'où... et pourquoi
Posté par BFG . Évalué à 6.
[^] # Re: Jusqu'où... et pourquoi
Posté par grid . Évalué à 6.
Ca me laisse le temps de lancer Eclipse, Open Office et Emacs.
[^] # Re: Jusqu'où... et pourquoi
Posté par Gniarf . Évalué à 2.
[^] # Re: Jusqu'où... et pourquoi
Posté par xenom . Évalué à 9.
Ensuite il y a les utilisateurs d'ordinateur portables.
Personnellement, quand j'allais en cours, les 30 secondes que mettait mon portable à démarrer était suffisant, mais plus cela aurait été pénible. Je ne faisais pas de suspend to ram, pour économiser de la batterie (batterie plus très performante et transport long, avec des utilisation répétés sur batterie.) et le suspend to disk etait plus long que de redémarrer, car le disque n'était pas très performant.
Je pense aussi à des systèmes particuliers (comme la, de la transmission vidéo) qui doivent être mobiles et démarrer rapidement, mais ne sont pas assez utilisé pour justifier la mise en veille.
[^] # Re: Jusqu'où... et pourquoi
Posté par Refuznik . Évalué à 1.
[^] # Re: Jusqu'où... et pourquoi
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
[^] # Re: Jusqu'où... et pourquoi
Posté par lolop (site web personnel) . Évalué à 2.
La question était l'intérêt de démarrer rapidement vs la mise en veille, surtout si on inclus le temps de rechargement des applications, qui s'ajoute au temps de boot et nécessite en plus l'intervention de l'utilisateur.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Jusqu'où... et pourquoi
Posté par totof2000 . Évalué à 3.
# Qt ?
Posté par zebra3 . Évalué à -5.
Faut dire aussi, quelle idée de prendre un framework aussi lourd. Il aurait pris du GTK, ils n'auraient pas eu tant de boulot :-)
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Qt ?
Posté par Anonyme . Évalué à 10.
Es-tu en train de dire que GTK gère tellement peut de chose que, forcément, y a rien à charger en mémoire ?
[^] # Re: Qt ?
Posté par Philippe F (site web personnel) . Évalué à 8.
Et oui, on est vendredi !
[^] # Re: Qt ?
Posté par Frédéric COIFFIER . Évalué à 10.
Par contre, je crois que le support framebuffer de Gtk est abandonné depuis, disons, 2003...
[^] # Re: Qt ?
Posté par Maxime Buffa . Évalué à 2.
[^] # Re: Qt ?
Posté par grid . Évalué à 10.
[^] # Re: Qt ?
Posté par totof2000 . Évalué à 3.
[^] # Re: Qt ?
Posté par windu.2b . Évalué à 10.
Ce qui prouve bien que GTK nécessite plus de mémoire que Qt :-p
[^] # Re: Qt ?
Posté par Maclag . Évalué à 2.
Ah! Zut! Quelques heures de retard...
# Merci :-)
Posté par Mali (site web personnel) . Évalué à -3.
Impressionant !
# j'ai parcouru le slide à partir de la page 17
Posté par NeoX . Évalué à 10.
(NB : j'utilise la numerotation du lecteur, et pas celle en bas de la slide.)
leur travail se base un uBoot et un kernel 2.6.31
on part d'un systeme qui boot le kernel en 2 sec
puis l'interface en 17sec
soit 19sec entre le poweron et un systeme utilisable
ensuite ils optimisent :
slide 22 :
ne pas compresser l'image du noyau si le support de stockage (memoire flash) est plus rapide que la decompressionslide 23 :
suppression de :
USB (144ms)
keyboard driver (4ms)
filesystem (0.8ms)
console output ( ?? )
optimisation sur :
delai d'initialisation de drivers (400ms)
delai divers (252ms)
eviter de chercher les cameras non connectées (200ms)
memset optimisé (161ms)
on passe ainsi de 1301ms à 113ms pour activer le kernel
puis on passe en "userland/userspace"
slide 25 :
suppression de :multiple scripts d'init pour n'en avoir plus qu'un (1.32s)
optimisation sur :
compilation en static avec uClibc
utilisation de SquashFS au lieu de JFFS (~6.81s)
reagencement en lancant QT puis la video
on passe alors de 8130ms à 64ms
slide 26 :
optimisation dans qt embeddedslide 28 à 30 :
optimisation de compilation pour limiter les acces disques au chargement des binaires et bibliothequesslide 32 :
TADDAH, un boot qui passe de 19sec à 0.77sec[^] # Re: j'ai parcouru le slide à partir de la page 17
Posté par Frédéric COIFFIER . Évalué à 3.
Il n'y a rien de révolutionnaire dans tout ce qu'ils citent : ce sont des choses qui ont déjà été faites unitairement sur différents projets depuis quelques années.
Le slide 33 est bien fait et les liste toutes.
Par contre, ils ont utilisés toutes les recettes (et certaines restent assez difficiles/longues à réaliser).
[^] # Re: j'ai parcouru le slide à partir de la page 17
Posté par superna (site web personnel) . Évalué à 1.
[^] # Re: j'ai parcouru le slide à partir de la page 17
Posté par Sekigo . Évalué à 4.
Là, c'est quasiment la même chose (sauf pour la partie QT) que les innombrables documentations glanée sur Internet (je n'ai aucun mérite). Et bien sûr, c'est inapplicable au desktop généralisé.
Je m'attendais à des trucs révolutionnaire quand j'ai vu le journal.
[^] # Re: j'ai parcouru le slide à partir de la page 17
Posté par bubar🦥 (site web personnel) . Évalué à 4.
perso sur un netbook je faisais tomber sans problème la barre des 19 secondes, il y a deux ans et demi (pffu ça passe trop vite) pour un bureau complet, chargé, et sans artifice genre "je démarre le réseau après". Très loin de ça, bien sûr, mais un netbook reste un desktop, et surtout ne me suis jamais attaqué à de telles modifs, sûr aussi ! Mais là, ça donne envie... ;)
[^] # Re: j'ai parcouru le slide à partir de la page 17
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: j'ai parcouru le slide à partir de la page 17
Posté par pasScott pasForstall . Évalué à 1.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: j'ai parcouru le slide à partir de la page 17
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
"La première sécurité est la liberté"
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.