Journal boot en une seule seconde

Posté par .
Tags : aucun
30
14
jan.
2011
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 :-)
  • # oubli

    Posté par . Évalué à 4.

    Pour les décideurs pressés : allez directement à la slide 28. La seule qui devrait réellement vous intéresser. Ensuite, la question que vous allez vous posez, ben j'ai pas trouvée la réponse...
    • [^] # Re: oubli

      Posté par . Évalué à 3.

      Slide 26
      (pas 28, sorry)
    • [^] # Re: oubli

      Posté par . Évalué à 10.

      La réponse que tu cherches est forcement sur la diapositive 42.
    • [^] # Re: oubli

      Posté par . Évalué à 4.

      En résumé, ils suppriment toutes les fonctionnalités nécessaires pour une machine générique. Donc forcément, ça va plus vite, mais ça me semble très difficilement généralisable.
      • [^] # Re: oubli

        Posté par . Évalué à 3.

        Enlever des fonctionnalités est un des différents moyen, mais il y en a plein d'autre comme l'optimisation des binaires executables.

        "La première sécurité est la liberté"

      • [^] # Re: oubli

        Posté par . Évalué à 5.

        Ouhai ça c'est le côté easy-for-everbody. Par contre j'voudrais bien le patch sur io.c moi
        • [^] # Re: oubli

          Posté par . Évalué à 10.

          En outre, ils ont amélioré memcpy pour U-Boot et memset pour le kernel. Je suis étonné que l'on puisse encore améliorer ces fonctions ou alors, ils les ont codé en assembleur pour la plateforme.

          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 (page perso) . Évalué à 3.

            En outre, ils ont amélioré memcpy pour U-Boot et memset pour le kernel. Je suis étonné que l'on puisse encore améliorer ces fonctions ou alors, ils les ont codé en assembleur pour la plateforme.

            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 (page perso) . Évalué à 2.

              Ça serait très étonnant.

              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 (page perso) . Évalué à 10.

        Il est dans le monde de l'embarqué le monsieur là. En particulier ce sont des machines qui ne sont pas fréquemment mise à jour qui servent à des usages bien définis et qu'on connait à l'avance puisqu'on a construit la machine pour.

        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 . Évalué à 6.

        Tu exagères: il y a aussi l'optimisation du temps de lancement des executables qui devrait pouvoir se généraliser.

        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 . Évalué à 2.

        Si tu veux quelque chose de plus généralisable, tu remplaces bêtement ton disque sata standard par un ssd.

        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 (page perso) . Évalué à 3.

    Salut,

    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 en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

    • [^] # Re: Jusqu'où... et pourquoi

      Posté par . Évalué à 6.

      Un redémarrage t'offre une garantie de propreté plus grande qu'un retour de veille. Il suffit d'un seul périphérique mal luné pour te planter le réveille.

      "La première sécurité est la liberté"

    • [^] # Re: Jusqu'où... et pourquoi

      Posté par (page perso) . Évalué à 3.

      Pour l'économie d'énergie il y a suspend to disk, non ?
      • [^] # Re: Jusqu'où... et pourquoi

        Posté par . Évalué à 2.

        J'ai essayé, quand j'utilise plus de 1.5Go de RAM, ça va plus vite de redémarrer que de sortir d'hibernation.
        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 (page perso) . Évalué à 2.

          c'est bizarre sur un ordinateur recent j'ai :


          /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 . Évalué à 1.

            Normalement, hdparm s'utilise sur un périphérique sata ou ide, pas une partition.

            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 (page perso) . Évalué à 2.

              merci, je n'était pas sur le bon peripherique

              /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 (page perso) . Évalué à 2.

          C'est étonnant vu que le démarrage fait des accès non séquentiels typiquement, donc très lents sur un disque dur.
          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 . Évalué à 6.

          Si vous utilisez plus d'1.5 GiB de RAM, il y a des chances que vous ayez de nombreuses applications à lancer après le redémarrage, et que cela prenne un temps à ne pas négliger.
    • [^] # Re: Jusqu'où... et pourquoi

      Posté par . Évalué à 9.

      C'est très utile pour l'embarqué. Un ordinateur de bord d'une voiture qui démarre en 1 minutes c'est beaucoup trop long, et même 10 secondes cela peut être trop long pour l'utilisateur. Si tu achetes une voiture haut de gamme, mais tu as un ecrans de chargement pendant 10 secondes sur ton autoradio/GPS/mains libres/.... c'est trop long.

      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 . Évalué à 1.

        Dans les voitures étrangères on trouve surtout TRON comme système.
      • [^] # Re: Jusqu'où... et pourquoi

        Posté par (page perso) . Évalué à 2.

        J'ai bien précisé pour une station de travail, je n'imagine pas une tablette interactive, un téléphone web, un truc GPS ou autre mettre 2 minutes avant d'être utilisable.

        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 en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

    • [^] # Re: Jusqu'où... et pourquoi

      Posté par . Évalué à 3.

      Ca se défend dans l'embarqué, si tu as un watchdog qui réinitialise le mattértiel dans le cas ou celui-ci ne répond plus.
  • # Qt ?

    Posté par . Évalué à -5.

    Il semble que le plus gros challenge a été d'optimiser le lancement de l'application Qt, qui avant modif prenait 7 secondes.

    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 (page perso) . Évalué à 10.

      Il aurait pris du GTK, ils n'auraient pas eu tant de boulot :-)

      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 (page perso) . Évalué à 8.

      C'est sur qu'ils auraient eu moins de boulot, ils n'auraient tout simplement jamais pu faire leur application !

      Et oui, on est vendredi !
    • [^] # Re: Qt ?

      Posté par . Évalué à 10.

      Un point important : Ils parlent de Qt mais pas de Xorg ! Normal car ils n'en ont pas besoin avec Qt.

      Par contre, je crois que le support framebuffer de Gtk est abandonné depuis, disons, 2003...
    • [^] # Re: Qt ?

      Posté par . Évalué à 2.

      Y'a encore des gens pour troll sur Qt/GTK malgré les grandes qualités de ces deux toolkits ?
      • [^] # Re: Qt ?

        Posté par (page perso) . Évalué à 10.

        C'est quoi les grandes qualités techniques de GTK ?
        • [^] # Re: Qt ?

          Posté par . Évalué à 3.

          Ne pas être Qt ? D'ailleurs, alphabétiquement, GTK est avant Qt, et il tient sur 3 lettres au lieu de 2 donc il est plus fort.
          • [^] # Re: Qt ?

            Posté par . Évalué à 10.

            "il tient sur 3 lettres au lieu de 2"
            Ce qui prouve bien que GTK nécessite plus de mémoire que Qt :-p
        • [^] # Re: Qt ?

          Posté par . Évalué à 2.

          C'est d'être de moins en moins utilisé dans l'embarqué, ce qui permet de troller sur les perfs supérieures qu'il aurait complètement invérifiables en pratique.

          Ah! Zut! Quelques heures de retard...
  • # Merci :-)

    Posté par (page perso) . Évalué à -3.

    Ici c'était café galette frangipane !

    Impressionant !
  • # j'ai parcouru le slide à partir de la page 17

    Posté par . Évalué à 10.

    Je vous en propose une rapide traduction :
    (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 decompression

    slide 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 embedded

    slide 28 à 30 :
    optimisation de compilation pour limiter les acces disques au chargement des binaires et bibliotheques

    slide 32 : TADDAH, un boot qui passe de 19sec à 0.77sec
    • [^] # Re: j'ai parcouru le slide à partir de la page 17

      Posté par . Évalué à 3.

      La console output, c'est l'affichage sur le port série (pour U-Boot ou le kernel). Dans ce cas, tu peux être limité par le baudrate (habituellement 115200bauds) et sur un boot Linux sans 'quiet', il y en a des choses à afficher.

      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 . Évalué à 4.

      Je suis deçu. Sur ma "défunte" mini-distribution linux pour la console de jeu dingoo a320, j'avais réalisé quelques une de ces optimisations, pour un résultat de ~ 2 secondes au pifomètre (je trouvais cela amplement suffisant, et c'était surtout pour éviter les process inutile en arrière plan).

      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 . Évalué à 4.

        A la fois + 1 et à la fois n'est ce pas aussi la beauté du truc ? Rien de révolutionnaire, du déjà connu, pour un résultat pas atteins par ailleurs (ou pas publiquement). Donc la beauté réside dans la qualité de l'implémentation. Non ?

        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 . Évalué à 3.

        L'optimisation du binaire n'est pas quelques choses de trivials et qui pourrait être fait sur un desktop.

        "La première sécurité est la liberté"

        • [^] # Re: j'ai parcouru le slide à partir de la page 17

          Posté par . Évalué à 1.

          Qu'est ce qu'ils entendent par optimisation du binaire?

          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 . Évalué à 4.

            L'ordre des fonctions C dépend de leur apparition dans le source. Ce n'est pas forcément l'ordre utile lors du démarrage. Il suffit donc de regrouper le code utilisé, cela permet de devoir lire beaucoup moins de secteurs différents sur le disque.

            "La première sécurité est la liberté"

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.