jeudi 24 juillet

Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Entretiens :: Suivi :: RDF

Articles précédents : Articles

Liens connexes

le site officiel (1209 hits)
Knoppix @ AlphaInc (177 hits)
la news clubic (648 hits)
la news distrowatch (96 hits)
l'article wikipédia sur cloop (174 hits)
le torrent (266 hits)

Dépêche modérée par

Floxy

Dépêche éditée par

Articles : Accelerated Knoppix : pour des Live-CD plus rapides

Posté par Erwann Robin (page perso, ). Modéré le 03 mars 2006.

Le système de fichiers cloop est conçu de telle manière que la lecture doit se faire par blocs compressés entiers. Cela rend cette méthode très lente quand les données sont éparpillées dans de petits blocs, surtout si le système a peu de mémoire.
La société Alpha Systems a eu l'idée d'optimiser l'emplacement des données préalablement à la gravure, et a lancé la distribution Accelerated Knoppix, une Knoppix optimisée pour démarrer en moins de 60 secondes !
Pour arriver à cette performance, ils ont optimisé l'image et le système de démarrage. Dans l'ordre des gains :

placement intelligent des octets dans l'image iso ;
profiling de l'image cloop ;
utilisation de initng pour booter en parallèle.

Toutes les distributions utilisant le système de fichiers cloop peuvent bénéficier de cette optimisation.

le site officiel (1209 hits)
Knoppix @ AlphaInc (177 hits)
la news clubic (648 hits)
la news distrowatch (96 hits)
l'article wikipédia sur cloop (174 hits)
le torrent (266 hits)

> Lire la dépêche (19 commentaires, moyenne: 4,7).

Voici le détail des optimisations utilisées

placement intelligent des octets dans l'image iso
un CD a un meilleur débit en périphérie qu'au centre, et pourtant les CD commencent par le milieu ; en plaçant les fichier utilisés au démarrage en périphérie, on double le débit de lecture !
profiling de l'image cloop
Cloop est le système de fichier compressé utilisé par Knoppix et la plupart des "live-cd" pour tout faire rentrer sur 1 CD. En changeant quelques paramètres, on accélère la lecture en même temps. (placement des fichiers nécessaires les uns à la suite des autres pour éviter le saut du laser du cd). Le système de démarrage lit l'image en un seul coup et conserve les parties inutiles en mémoire, en prévoyant qu'elle sera appelée plus tard.
utilisation de initng pour booter en parallèle
InitNG est la future version des scripts d'initialisation qui sera bientôt intégrée dans la plupart des distributions (initNG ou des dérivés comme pinit pour Mandriva). En même temps, on en profite pour virer les services inutiles, et lancer le minimum de services pour permettre le démarrage de X.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

Bravo !!!

Posté par Stéphane Téletchéa (page perso, ) le 03/03/2006 à 14:00. (lien). Évalué à 3.

Bravo pour la news et très bien pour l'optimisation.

Il est vrai que dans de nombreux LiveCD il y a de nombreux allers et retours avec le CD quand on veut utiliser son ordi "comme on en a l'habitude" en lançant plusieurs programmes à la fois.

Avec cette optimisation on devrait avoir une nette amélioration et pour faire des démonstrations, cela facilitera d'autant la pertinence du système.

De plus pour les ordinateurs portables qui ont des débits d'accès plus lents, cela devrait significativement augmenter la qualité d'utilisation.

[^]Re: Bravo !!!

Posté par gnuk (page perso, ) le 03/03/2006 à 15:39. (lien). Évalué à 10.

« Il est vrai que dans de nombreux LiveCD il y a de nombreux allers et retours avec le CD quand on veut utiliser son ordi "comme on en a l'habitude" en lançant plusieurs programmes à la fois. »

Il s'agit ici d'une optimisation uniquement pour la séquence du boot, la procédure de démarrage étant connue à l'avance dans la plupart des cas.
Je ne pense pas, par contre, que les applications lancées « comme à l'habitude » gagnent en performance (en tous cas de facon aussi significative que le démarrage de la machine), étant donné qu'il est difficile de prévoir ce genre de comportement.

C'est malgré tout une bonne chose, ca permettra peut-être d'accélérer le dévellopement des "nouveaux" systèmes de démarrage comme mentionné plus haut, pinit et initng par exemple.

[^]Bravo ???

Posté par technojoly () le 06/03/2006 à 18:54. (lien). Évalué à 1.
Bonjour

j'ai chargé et gravé une image de cette version (knoppix 3.9) et je l'ai lancée chez moi le temps de lancement de knoppix ne semble pas très bon. Mais comme c'est une vieille machine j'essaye ce live CD au travail.

Résultat sur un pc hp 3.4 GO 512 MO memoire :

Accelerated knoppix : 2 min aprés avoir appuyé sur entrée, à la suite de la ligne de commande : knoppix lang=fr

knoppix live cd 4.0.2 : 1 min 45 aprés avoir appuyé sur entrée, à la suite de la ligne de commande : knoppix lang=fr

en fait sur plusieurs pc de l'entreprise même phenomene (meme sur un serveur de prod)

Ai-je chargé une version non optimisée ??

Init

Posté par patrick_g (page perso, ) le 03/03/2006 à 14:09. (lien). Évalué à 8.

D'après ce que j'avais cru comprendre pinit et initng c'est pas la même chose.
j'avais lu que pinit c'était juste le lancement de certains scripts en parallèle mais que ce concept reste limité et est compatible avec le LSB (Linux Standard Base).
Mandriva utilise (ou va utiliser) ce système.
Par contre il me semble qu'initng est une solution beaucoup plus radicale de réorganisation complète du lancement des scripts de démarrage. C'est potentiellement beaucoup plus efficace que pinit mais c'est pas compatible LSB et donc beaucoup de distros n'y sont pas favorable.
Y'a qq dans la salle qui peut confirmer/infirmer/préciser ?

[^]Re: Init

Posté par Erwann Robin (page perso, ) le 03/03/2006 à 14:31. (lien). Évalué à 6.
tout à fait : http://archives.mandrivalinux.com/cooker/2005-10/msg00256.ph(...)
Pour une accélération complète , cela nécessite de réécrie les scripts de démarrage, mais pinit reste compatible avec les scripts bruts.

Pour choisir l'ordre des services à démarrer, pinit se base sur l'ancienne méthode compatible LSB : appeler les scripts dans /etc/rcX.d/ en commencant par S pour start puis un numéro qui précise à quel moment le démarrer
mais ajoutte des infos de dépendances amon et aval en commentaire dans ces mêmes scripts

ainsi, les scripts non-migrés seront simplement lancés comme avant, quand ce sera leur tour, et les scripts migrés restent compatibles LSB.

pinit est activé par défaut dans cooker et les tests montrent une accélération notable du démarrage et de l'arrêt.

Maintenant, il reste à accélérer le lancement des interfaces graphiques
- [^]Re: Init
  
  Posté par reno () le 04/03/2006 à 12:07. (lien). Évalué à 4.
  >Maintenant, il reste à accélérer le lancement des interfaces graphiques
  
  Pas tout à fait..
  
  Ce que je trouve amusant dans la thread que tu as linké, c'est qu'il y a un utilisateur pour lequel pinit fait passér de 46s à 42s, et il trouve que c'est une indication comme quoi le système est bien optimisé.
  
  Ca plus ta remarque, c'est plutôt amusant: BeOS sur une machine bien moins puissante que maintenant démmarait en 14s (du boot loader à l'interface graphique fonctionnelle et sans aucune optimisation de ma part).. Ce temps correspondrait sous Linux au boot du kernel *plus* le demarrage d'une interface graphique en "auto-login"!
  
  Ce n'est pas prés d'arriver sous Linux, malheureusement..
  - [^]Re: Init
    
    Posté par Olivier (page perso, ) le 04/03/2006 à 14:30. (lien). Évalué à 4.
    BeOS sur une machine bien moins puissante que maintenant démmarait en 14s (du boot loader à l'interface graphique fonctionnelle et sans aucune optimisation de ma part)..
    
    Il faudrait peut-être comparer ce qui est comparable : Ton BeOS n'avait pas à gérer xx interfaces réseaux différentes (et d'ailleurs, combien existait-il de drivers pour les cartes réseaux ?), du Wifi, de l'IPv6, du Bluetouth, et j'en passe et des meilleurs...
    
    Ce que je te faire comprendre c'est qu'avec le temps, Linux s'est diversifié à un point qui n'était pas imaginable à l'époque de ton BeOS, et que dans ce cas, le nombre même de tests à faire pour démarrer le système est nettement plus conséquent.
    
    Prenons un exemple tout simple : Le script de démarrage des couches réseaux d'un Linux. Sur ma MDK, mais c'est sensiblement la même chose pour les autres distributions, le script "/etc/init.d/network" fait 359 lignes. Dedans : du bash qui lance toutes sortes de programmes (awk, ifconfig, etc..), afin de prendre en compte plein de types de configurations de réseaux différentes. Mais si tu veux quelque chose de beaucoup plus rapide pour UNE configuration particulière, cela peut se régler en 3 lignes de bash. Voir à quelques lignes de C, ce qui permettrait en plus d'éviter de lancer l'interpereur bash.
    
    Pourquoi ne pas plus optimiser ainsi tout les scripts alors ? Parce qu'il perdrait pas mal de lisibilité pour les utilisateurs, et qu'ils seraient forcément moins souples.
    
    De plus, il existe tout un tas de programmes qui se chargent automatiquement au démarrage de la machine : serveur de fontes, portmap, serveur SMB, serveur web, firewall, HAL, etc... Tout cela dans le but de rendre la vie de l'utilisateur plus simple, sans qu'il n'ait besoin d'activer manuellement des parties de softs lorsque l'occasion se présente. L'utilisateur veut ne pas avoir à se poser de questions lorsque qu'il est sur sa machine. Cela nécéssite donc de charger dans le système des méchanismes complexes.
    
    Enfin, dans la philosphie de Unix/Linux, il n'est pas habituel de redémarrer son ordinateur : Ce type de machine a été conçu pour être allumé et ne (presque) pas s'arrêter. C'est l'utilisateur actuel qui a sans cesse besoin de l'éteindre et de le rallumer... Ce qui fait au passage des économies d'énergie, ce qui n'est pas forcément plus mal... ;)
    
    Conclusion :
    - Linux est long à booter : Oui
    - Linux charge plein de trucs inutiles : Oui, afin de faciliter l'utilisation pour l'utilisateur "newbee".
    - Le chargement de Linux peut être optimiser : Oui, et très largement :
    + Compilation du kernel pour ne charger que les modules utiles
    +Ne pas charger les softs inutiles (par exemple, pour certains un serveur web n'est pas utile)
    + Ré-écriture des méchanismes d'init. Sur une machine définie, un script d'init unique de quelques dizaines de lignes permettrait de tout lancer.
    - [^]Re: Init
      
      Posté par Matthieu C () le 04/03/2006 à 19:00. (lien). Évalué à 4.
      - Linux est long à booter : Oui
      - Linux charge plein de trucs inutiles : Oui, afin de faciliter l'utilisation pour l'utilisateur "newbee".
      - Le chargement de Linux peut être optimiser : Oui, et très largement :
      
      [mode pinailleur]
      Pourtant les Linux que l'on trouve en embarqué boot en quelques secondes...
      De meme ma slack bootait tres rapidement (~30s) sur un vieux 133 Mhz.
      
      C'est pas Linux qui est lent mais l'initialisation fait par les scripts de ta distribution pour apporter tout le confort dont tu parles.
      [/mode pinailleur]
    - [^]Re: Init
      
      Posté par reno () le 04/03/2006 à 22:14. (lien). Évalué à 3.
      >le nombre même de tests à faire pour démarrer le système est nettement plus conséquent.
      
      Bof, si c'est vraiment ça la raison qui retarde le démmarrage pourquoi tester à *chaque* démmarrager??
      On ne change pas de matériel touts le temps et il suffirait d'ajouter un outil pour voir les changements (quitte à rebooter si nécéssaire).
      
      BeOS n'avait pas beaucoup de drivers, c'est vrai mais ce n'était quand même pas une configuration figée: c'etait plus un probleme de ressource qu'une volontée.
      
      > Enfin, dans la philosphie de Unix/Linux, il n'est pas habituel de redémarrer son ordinateur
      
      La philosophie dépend du besoin, pas de l'OS: ok on n'arrète pas les serveurs dans leur salle machine, mais dans mon studio mon ordinateur (pourtant très silencieux) est trop bruyant pour que je le laisse allumer la nuit si je veux dormir.
      
      Et je me répète: BeOS faisait 14s *sans optimisation de l'utilisateur* et ce temps inclue le démmarrage du desktop (fonctionnel pas comme sous WindowsXP) alors que souvent sous Linux dans le temps de boot on ne compte pas le démmarrage de Gnome ou KDE, certes j'imagine qu'il y avait quelques fonctionnalité en moins dans BeOS (je ne me souviens plus trot), mais l'interface graphique en plus!
      
      Pour ce qui est des serveurs présents par défaut, je pense (et j'espère ne pas me tromper) que ce n'est plus trop le cas sous Linux, d'un point de vue sécurité, c'est une très mauvaise idée!
      - [^]Re: Init
        
        Posté par Olivier (page perso, ) le 05/03/2006 à 17:48. (lien). Évalué à 0.
        Bof, si c'est vraiment ça la raison qui retarde le démmarrage pourquoi tester à *chaque* démmarrager??
        
        Tout simplement pour rendre la machine plus flexible, et capable de s'adapter "out of the box" sur une nouvelle machine/configuration.
        
        Imagines :
        - Tu installes ta distribution favorite sur une machine "A".
        - Tu démontes le disque dur, et tu le mets dans une machine "B", physiquement différente de "A" : Pas les mêmes cartes mêres, réseaux, vidéo, etc...
        - Lors du boot de "B", il y a de très fortes chances pour que le Linux se configure tout seul sur ce nouveau hardware, et soit opérationnel tout de suite.
        
        C'est l'usage que l'on fait de l'Informatique au jour d'aujourd'hui (2006) qui veut cela : La configuration d'une machine doit être la plus transparente possible du point de vue de l'ordinateur. Même si cela doit couter une débauche de temps CPU, et de mémoire vive...
        
        On ne change pas de matériel touts le temps et il suffirait d'ajouter un outil pour voir les changements (quitte à rebooter si nécéssaire).
        
        Tu aimes tant que cela les reboots de Windows ? :)
        
        Et je me répète: BeOS faisait 14s *sans optimisation de l'utilisateur* et ce temps inclue le démmarrage du desktop
        
        Et j'imagine que ton BeOS savait gérer :
        - L'"export display", qui permet d'envoyer de maniètre transparente l'affichage d'une application sur un écran situé à distance
        - Le multi-écrans
        - Les effets de transparences, d'ombrages, etc...
        - Les périphériques amovibles, genre USB, firewire, etc...
        - La 3D (OpenGL)
        - Le directrendering (qui permet par exemple d'afficher de la video directement sur le chipset graphique)
        - Pouvait utiliser plusieurs toolkits graphiques différents (KDE, Gnome, vxWidget, OpenOffice.org, Mozilla, etc...)
        - Etc...
        
        En terme de "look pur", je me souviens de screenshots de BeOS de l'époque. Par rapport aux Windows de l'époque, c'était équivalent. Mais par rapport à ce que l'on peut avoir sur un Linux, il n'y a pas photo. Or, toute cette débauche de couleurs et d'effets graphique des Linux, il faut bien le payer à un moment donné, non ?
        
        Pour ce qui est des serveurs présents par défaut, je pense (et j'espère ne pas me tromper) que ce n'est plus trop le cas sous Linux, d'un point de vue sécurité, c'est une très mauvaise idée!
        
        Lance un "netstat -taupn" sur ta machine, tu auras une bonne vue des serveurs qui y tournent.
        
        Quand à sécuriser ces serveurs, comme je l'explique ici http://olivieraj.free.fr/fr/linux/information/firewall/fw-02(...) c'est généralement faisable facilement. Sachant qu'en 2nd couche, on peut rajouter Netfilter, le firewall de Linux.
        
        [^]Bou le vilain troll !
        
        Posté par Erwann Robin (page perso, ) le 06/03/2006 à 09:57. (lien). Évalué à 2.
        > Et j'imagine que ton BeOS savait gérer :
        > - L'"export display", qui permet d'envoyer de maniètre transparente l'affichage d'une application sur un écran situé à distance
        > - Le multi-écrans
        > - Les effets de transparences, d'ombrages, etc...
        > - Les périphériques amovibles, genre USB, firewire, etc...
        > - La 3D (OpenGL)
        > - Le directrendering (qui permet par exemple d'afficher de la video directement sur le chipset graphique)
        > - Pouvait utiliser plusieurs toolkits graphiques différents (KDE, Gnome, vxWidget, OpenOffice.org, Mozilla, etc...)
        > - Etc...
        oui oui tout ca !
        
        pour plus d'infos :
        export display : VNC (?)
        pas de serveur X forcément, mais un Display Kit très très au point !
        BeOS était appelé le multimédia OS, capable en 98 d'afficher un cube en 3D qui tournait (openGL) et dont chaque face affichait une vidéo !
        (et tout ca sur un pentium 200).
        
        et tout était libre à part le kernel :(
        
        plus d'infos : http://www.beosfrance.com/systemes.php
    - [^]Re: Init
      
      Posté par Geoffroy Carrier (Jabber id, page perso, ) le 05/03/2006 à 16:53. (lien). Évalué à 2.
      La meilleure solution reste a mon humble avis un bon support du suspend to ram, voire suspend to disk pour des consommations minimales d'energie.
      S'il est vrai que l'ordinateur doit etre regulierement "coupe" de nos jours, cela ne veut pas dire que la partie logicielle doit etre a chaque fois reinitialisee...
      Sur mon ibook 12", je ne redemarre qu'apres des grosses mises a jour logicielles... Il faut dire que suspendu (suspend to ram automatique quand je ferme l'ecran), il tient sans probleme quelques jours.

Super Efficace !

Posté par jeff110 () le 03/03/2006 à 16:50. (lien). Évalué à 7.

J'ai telecharger le live-cd hier, et j'ai été vraiment tres impressionné !
Une rapidité digne d'un disuqe dur .
Par contre, il y a du japonais dans tous les coin, c'est pas tres comprehensible ...

Vivement la prochaine version de kaella avec ces nouvelles optimisation .

[^]Re: Super Efficace !

Posté par dark_star () le 04/03/2006 à 13:57. (lien). Évalué à 6.
en plus on entends presque plus le lecteur cd, il doit beaucoup moins souffrir qu'avant.

meme en demarrant openoffice ou konqueror c'est tres rapide et toujours presque pas de bruit.

Temps de boot

Posté par Maxime (Jabber id, ) le 04/03/2006 à 00:26. (lien). Évalué à 5.

Je sais pas vous mais pour moi, 60 secondes ca me parle pas trop... Avant l'optimisation, sur la même machine, il fallait combien de temps ? Car dans l'optimisation, ce que j'aime entendre c'est de combien on gagne... D'ailleur ca serai bien d'avoir l'info sur la machine de test (vitesse du lecteur, taille ram, proc etc...)

[^]Re: Temps de boot

Posté par Fabien Engels (page perso, ) le 04/03/2006 à 09:57. (lien). Évalué à 6.
Tu prends une knoppix 4.02 et ce livecd, un emontre, et tu nous fais un benchmark ? ;)

C'est vrai que ça pourrait etre interressant d'avoir des chiffres concrets (trop pragmatique les informaticiens ? :) )
- [^]Re: Temps de boot
  
  Posté par Fabien Engels (page perso, ) le 04/03/2006 à 17:29. (lien). Évalué à 10.
  J'ai pris le temps de faire la comparaison, pour les deux boots j'ai utilisé comme option: knoppix lang=fr screen=1280x1024
  
  Knoppix 4.02 : 1min45
  Knoppix Accelerated : 45sec
  
  Soit une reduction de 57% du temps de démarrage, pas mal :)
  
  conf de test:
  P4 3Ghz
  1Go de RAM
  Lecteur 48x

[^]Re: Temps de boot

Posté par Erwann Robin (page perso, ) le 04/03/2006 à 10:06. (lien). Évalué à 2.
c'est sûr que si tu n'a jamais essayé knoppix, c'est pas gagné.
en gros, le temps de démarrage dans ce cas est très limité par le lecteur CD lui-meme, et quelque soit la machine.

knoppix démarre normalement en 3 minutes environ, 2 si on reste en init 3 (mode texte), alors que ce nouveau système divise le temps de boot par 3 !!
- [^]Re: Temps de boot
  
  Posté par Maxime (Jabber id, ) le 04/03/2006 à 10:41. (lien). Évalué à 6.
  wah, je me souvenais pas de temps aussi long... que le temps passe vite quand je suis sur mon ordi...

Revenir en haut de page

Articles précédents : Articles

Liens connexes

Dépêche modérée par

Dépêche éditée par

Articles : Accelerated Knoppix : pour des Live-CD plus rapides

Bravo !!!

[^]Re: Bravo !!!

[^]Bravo ???

Init

[^]Re: Init

[^]Re: Init

[^]Re: Init

[^]Re: Init

[^]Re: Init

[^]Re: Init

[^]Bou le vilain troll !

[^]Re: Init

Super Efficace !

[^]Re: Super Efficace !

Temps de boot

[^]Re: Temps de boot

[^]Re: Temps de boot

[^]Re: Temps de boot

[^]Re: Temps de boot