# [OFF] combien de tps au demarrage?

## pathfinder

salut, 

j aimerais avoir une idee du tps que met votre pc a demarrer. le mien tarde entre 43 et 51 secondes, en me loguant puis fluxbox via startx, conky etant en route pour fluxbox. je trouve ca assez decevant, j avais entendu que chez certains c etait environ 20 secondes...

le type de PC?              chez moi, P3 a 1000 avec 256 RAM. portable.

les services lances au demarrage?

 *Quote:*   

> 
> 
> pathfinder ~ $ ls -l /etc/runlevels/boot/
> 
> total 0
> ...

 

P.S.:/edit: j ai rajoute hdparm et dbus (skype).

hdparm je sais pas encore...

et j ai un USB 20 Go branche au demarrage. il le cherche pour le monter quand il n y est pas.

----------

## bong

<troll qui pue>

C'est pas le temps de démarrage qui compte, c'est le temps qu'il tient avant le premier reboot 

</troll qui pue>

Perso, je m'en fiche du temps qu'il met a démarrer, je l'eteint jamais   :Very Happy: 

----------

## razer

Perso, grâce à software suspend2, moins de 20 secondes...

Sans, environ 3 fois plus...

Tu sembles insinuer que tu as un portable : les disques dûrs de ces derniers sont généralement plus lents, tout comme le reste...

----------

## guilc

Bah perso, jamais chronométré, et plutot rien a faire : je reboote quasiment jamais mes machines, donc bof, que ça mette 15s ou 1 minute, je m'en fout un peu  :Mr. Green: 

----------

## pathfinder

voila qui est interessant... software suspend...

mais je crois qu il faut un kernel assez nouveau, ou alors patcher un ancien (jamais fait, je suis pas fan, e prefere en configurere un nouveau, sauf que le dernier tente, le r5, me donnait quelques erreurs pas bien graves au demarrage, et j aime pas ca... et il tardait plus que le r2 que j utilise actulelement)

 *Quote:*   

> # emerge -pv suspend2-sources
> 
> These are the packages that I would merge, in order:
> 
> Calculating dependencies ...done!
> ...

 

c est faisable sur mon kernel sans patcher?

----------

## UB|K

 *pathfinder wrote:*   

> c est faisable sur mon kernel sans patcher?

 

Sans patcher? non. En plus, le patch passe pas toujours sur un kernel gentoo, il vaut mieux patcher sur un kernel vanilla (plus d'autres patch comme vesafb, gensplash ...) ou utiliser les suspend2-sources (encore mieux: il n'y a rien à faire).

Après, je dirais que ça dépend de ta carte vidéo: les cartes nvidia ont visiblement des problèmes avec le resume. 

Sur un portable, c'est un fonction super intéressante car on l'éteind/reboot plus souvent qu'une machine de bureau (enfin pour moi, c'est le cas) et le gain de temp est vraiment appréciable.

Dans un autre genre, il y a aussi le nouvel "init": initng qui poutre grave mais c'est pas encore tout à fait au point (pas mal de scripts ne marchent pas parfaitement et d'autres n'existent pas encore).

----------

## yoyo

 *UB|K wrote:*   

> Sans patcher? non. En plus, le patch passe pas toujours sur un kernel gentoo, il vaut mieux patcher sur un kernel vanilla (plus d'autres patch comme vesafb, gensplash ...) ou utiliser les suspend2-sources (encore mieux: il n'y a rien à faire).
> 
> Après, je dirais que ça dépend de ta carte vidéo: les cartes nvidia ont visiblement des problèmes avec le resume. 

 Pour tout ça, je te conseille le patchset cj-sources réalisé par LostControl, un p'tit gars kinenveux du forum.

Dans le thread qui est consacré à ce patchset, une soluce est donnée pour le module nvidia-kernel et ses libs glx.

Enjoy !

----------

## nico_calais

J'ai jamais chronometré mes boots mais ayant un PC sous Gentoo (Gnome) et celui d'à côté sous windows, j'ai remarqué que ma gentoo box était plus rapide au démarrage. Bien que j'arrive à avoir le bureau de windows plus vite, ce dernier met plus de temps à charger les différents services.

----------

## kopp

Tiens, ppierre dit des choses intéressantes dans ce thread.

c'est un peu vieux alors peut etre que ce n'est plus d'actualité mais je ne pense pas  :Smile: 

----------

## geekounet

Ben chez moi ça fait 50 sec avec sysvinit, et 15 avec initng   :Cool: 

----------

## Enlight

 *pierreg wrote:*   

> Ben chez moi ça fait 50 sec avec sysvinit, et 15 avec initng  

 

Gnééééé???

----------

## spider312

Pour mon ordinateur portable, du kernel au Login Manager de X (entrance) : 

Avec sysvinit : 42s : http://columbia.rs2i.net/~spider/image_gallery/bootchart-raoul-init.png

Avec initng : 19s : http://columbia.rs2i.net/~spider/image_gallery/bootchart-raoul-initng.png

Des petites pistes pour optimiser tout ça : 

 - initng est un remplacement optimisé à sysvinit, car sysvinit n'est clairement pas fait pour la vitesse (rien que dans mon exemple, temps divisé par 2, presque le même gain que software-suspend, et pour un reboot propre)

 - bootchart, le logiciel avec lequel j'ai fait ces graphs, permet de voir ce qui prends du temps, à recouper avec rc-update, et tous les fichiers de /etc/conf.d, certaines operations sont un gouffre à temps (en particulier l'attente des réponses DHCP), et certains services sont démarés pour rien suite à un tuto pas forcément clair, personellement, je fais confiance aux dépendances, et je ne mets en démarage automatique que les services dont je connais le fonctionnement et dont j'ai réelement besoin

----------

## Enlight

Ben oui mais bon tu lances 4 fois plus de trucs avec l'ancienne version d'init (d'ailleurs pourquoi tout le monde dit sysvinit5, pour moi  c'est le modèle de communication du noyau)).

Pour ma part je pense surtout que le gain de rapidité vient du fait que les scripts allant avec initng utilisent massivement les "&" et qu'init n'est pas un problème en soit... et pour le monitoring, je ferais bien plus confiance à l'utilisation d'outils tels que daemontools (ce que ne fait pas gentoo).

Il me semble surtout que la différence c'est qu'initng intègre le rc-script (à vérifier) qui gère les runlevels, mais dans ce cas, une ré-écriture en perl et tu pourras sentir le vent dans tes cheveux au démarrage de ton engin  :Mr. Green: 

----------

## sireyessire

 *Enlight wrote:*   

> Ben oui mais bon tu lances 4 fois plus de trucs avec l'ancienne version d'init (d'ailleurs pourquoi tout le monde dit sysvinit5, pour moi  c'est le modèle de communication du noyau)).
> 
> Pour ma part je pense surtout que le gain de rapidité vient du fait que les scripts allant avec initng utilisent massivement les "&" et qu'init n'est pas un problème en soit... et pour le monitoring, je ferais bien plus confiance à l'utilisation d'outils tels que daemontools (ce que ne fait pas gentoo).
> 
> Il me semble surtout que la différence c'est qu'initng intègre le rc-script (à vérifier) qui gère les runlevels, mais dans ce cas, une ré-écriture en perl et tu pourras sentir le vent dans tes cheveux au démarrage de ton engin 

 

tu sembles insinuer que bash est plus lent que perl, tu as des chiffres pour valider ça? (parce qu'instinctivement je les mettais dans le même tas des langages interprétés mais je me suis pas trop posé la question en fait)

en tout cas moi je dis que le C ou l'asm ça torche plus mieux, na!

----------

## Enlight

D'une manière générale oui, bash est extrèmement lent, voir ce lien.

http://lists.canonical.org/pipermail/kragen-tol/2000-April/000571.html

après en principe perl devrait être bien plus rapide que python pour ce que j'ai lu de ci, de là (mais je pense que ça va bien plus dépendre du codeur), en revanche la différence entre bash et {perl,python} est réellement saisissante.

 *extrait wrote:*   

>     GForth: 10 times slower than C
> 
>         pfe: 10 times slower than C
> 
>      pforth: 25 times slower than C
> ...

 

edit : par contre perl et python (ruby aussi probablement) ne sont paq des "vrais" langages interprétés il me semble qu'il y'a une sorte de pré-compile.

----------

## bibi.skuk

 *Enlight wrote:*   

> 
> 
> edit : par contre perl et python (ruby aussi probablement) ne sont paq des "vrais" langages interprétés il me semble qu'il y'a une sorte de pré-compile.

 

exact, enfin, presque... quelques precisions (je sais pas pour ruby), 

python genere un byte-code qu'il sauve sur le disque et ensuite execute celui-ci (c'est le fichier *.pyc dans le même rep que le script), et ensuite, si le fichier existe, il l'execute tout de suite... en gros, il compile a la premiere execution. Avis aux testeurs, ne pas lancer l'appli 2 fois pour se dire qu'elle est lente, il faut toujours la lancer au moins 2 fois pour commencer a voir si c'est plus rapide.

Quand à perl de son coté, comme pas mal de language interpretés, il parse le code, genere son byte-code et l'execute a la volée, mais ne le stocke pas (bien que ça soit possible). Par contre, j'ai toujours trouvé les appli en perl plus rapides que celles en python (à condition qu'elle n'aient pas été codées avec les pieds for ( 1 .. 1000 ) {} et autres betises...)

Pour ne pas faire un post totalement HS, je boot en 45 sec avec le vieux init et en a peu pres 15s avec initng (mais j'avait pas les mêmes services de lancés exactement... il faudrait que je reteste...) et avec init=/bin/bash, ca prend 2sec  :Very Happy: 

Edit : a propos de bash...

 *man bash wrote:*   

> 
> 
> BUGS
> 
>        Its too big and too slow.
> ...

 

tout est dit :p

----------

## blasserre

 *Enlight wrote:*   

> D'une manière générale oui, bash est extrèmement lent, voir ce lien.

 

c'est un peu la différence entre un interprêteur de commandes et un language de script, non ?

sinon j'ai retrouvé ce site de benchmark de languages sur différents points, juste pour dire qu'en plus de l'implémentation, la vocation finale du script fait aussi varier grandement les temps d'éxécution.

----------

## guilc

Ouef, enfin, dire que bash est beaucoup plus lent que perl... A tempérer je dirais. Je m'explique :

Pour un gros script, OK, j'accepte les benchs, bash est plus lent. MAIS pour un petit script comme on en voit tant, je ne suis pas persuadé du tout. Avant l'exécution du script perl, il faut lancer la machine perl, faire un gros parsing du code, et tout ça, mine de rien, sur un petit script, c'est l'immense majorité du temps, et la, bash va completement écraser perl... Un peu comme la facturation a la seconde moins chere en perl qu'en bash, mais après une première minute indivisible a un prix astronomique   :Laughing: 

Enfin, bref, tout ça pour dire qu'il faut pas prendre les benchs au pied de la lettre, ça dépend aussi de l'utilisation qu'on en fait.

Mes 2 cents

----------

## Enlight

Vu la quote de bibi.skuk je parierais pas! Même en première execution (voir ce qui a été dit plus haut), de tous petits scripts perl (je débute hein!) sont beaucoup plus rapides que ceux en bash.

De plus bash est plus limité, dans la mesure où on fait presque tout le temps appel à des programmes extenes, ça oblige sans cesse à la création de nouveaux processus avec le fork et le wait "quivontbien".

----------

## bibi.skuk

 *Enlight wrote:*   

> Vu la quote de bibi.skuk je parierais pas! Même en première execution (voir ce qui a été dit plus haut), de tous petits scripts perl (je débute hein!) sont beaucoup plus rapides que ceux en bash.
> 
> De plus bash est plus limité, dans la mesure où on fait presque tout le temps appel à des programmes extenes, ça oblige sans cesse à la création de nouveaux processus avec le fork et le wait "quivontbien".

 

tututut... je viens de faire quelques tests avec un "hello world" en perl et en bash... bash semble plus rapide... par contre, je vais essayer de pousser le test un peu plus loin... mais a mon avis... la suprematie de bash s'arrete la.  :Smile:  enfin, je vais tester avant de confirmer ce que j'avance.

mais le problème, c'est sur quoi tester ? de la recherche de fichiers ? du parsage de textes ? un peu des 2 ? on connait deja le resultat... (attention, c'est pas un test de simplicité de codage, mais plutot de perf... apres, pour le temps que tu met a le coder, c'est autre chose...)

----------

## kaworu

[noob]

comment peut-on switcher ne sysvinit à initng (faut emerger, recompiler le kernel ???)

[/noob]

thx !

----------

## Enlight

 *bibi.skuk wrote:*   

>  *Enlight wrote:*   Vu la quote de bibi.skuk je parierais pas! Même en première execution (voir ce qui a été dit plus haut), de tous petits scripts perl (je débute hein!) sont beaucoup plus rapides que ceux en bash.
> 
> De plus bash est plus limité, dans la mesure où on fait presque tout le temps appel à des programmes extenes, ça oblige sans cesse à la création de nouveaux processus avec le fork et le wait "quivontbien". 
> 
> tututut... je viens de faire quelques tests avec un "hello world" en perl et en bash... bash semble plus rapide... par contre, je vais essayer de pousser le test un peu plus loin... mais a mon avis... la suprematie de bash s'arrete la.  enfin, je vais tester avant de confirmer ce que j'avance.
> ...

 

Oui enfin j'ai quand même passé le cap du Hello World!  :Mr. Green: 

----------

## bibi.skuk

 *kaworu wrote:*   

> [noob]
> 
> comment peut-on switcher ne sysvinit à initng (faut emerger, recompiler le kernel ???)
> 
> [/noob]
> ...

 

emerge initng et ensuite pour grub il faut faire init=/sbin/initng et apres, c'est la man...

@Enlight : ca, j'avait remarqué, mais c'etait pour le test...

----------

## nuts

 *bibi.skuk wrote:*   

>  *kaworu wrote:*   [noob]
> 
> comment peut-on switcher ne sysvinit à initng (faut emerger, recompiler le kernel ???)
> 
> [/noob]
> ...

 

et au niveau des demons a lancé au demarrage, ca prends ceux en compte par le rc-update ou faut tout passer avec ng-update ?

----------

## bibi.skuk

 *nuts wrote:*   

>  *bibi.skuk wrote:*    *kaworu wrote:*   [noob]
> 
> comment peut-on switcher ne sysvinit à initng (faut emerger, recompiler le kernel ???)
> 
> [/noob]
> ...

 

il faut passer par ng-update (logique...)

----------

## nuts

j'ai testé, c'est vrai qu'au niveau boot c'est fulgurant. par contre il y a des script qui passe bien avec rc-update et pas du tout avec ng-update tel que hdparm timidity hotplug vsftpd. et pour finir au lieu de me lancer gdm je me tape un xdm tout moche

----------

## -KuRGaN-

Ben moins un peu comme tout le monde, je ne reboot jamais, enfin, le moins possible   :Laughing: 

Sinon, le temps de lancer mon système xen, je dois mettre 40s et ensuite chaque serveur virtuel se démarre en 20s a peu près   :Wink: 

----------

## pathfinder

ok merci de cette discussion riche en elements

c est excellent

je resume GROSSSISSSIMO MODO, pour ce qui m interesse, je dois e pencher sur suspend2, mais faut recompiler le noyau, et c est ps que j aime pas, c est que ca prend su temps, et j ai trrop souvent des petits messages (insignifiants) d erreur type warning ou autre qui m agacent...

l autre truc, apparemment genial, c est 

initng

j emerge des que possible

et je man

c est bon a savoir.

mon desktop je l eteins jamais, ou presque, c est vrai, et je m enfiche un peu, c est juste une question d optimisation...

le portable, c est different, puisque c est constamment eviter qu il ne surchauffe ou je dois le ranger pour qu on ne le vole pas, etc...

donc c est bon a savoir!

j essaierai de me payer le luxe d avoir un kernel avec hibernate

et un autre avec initng.

derniere question: vous avez un initrd au demarrage de votre gentoo?

je me rappelle, la premiere fois que je  l avais installe, il y en avait un. mais apres, stage3, il etait pas marque dans la doc d en faire un, et a vrai dire, ca passe bien sans...

donc il s agirait de rajouter un initng, c est ca?

MErcie en tout cas pour toutes ces infos

un plaisir

une bonne journee a tous

----------

## nuts

j'ai installé initng, je dois dire que ca boost bien, mais actuellement je prefere avoir mon systeme plus lent. le truc qui me derange en fait, c'est que ca ne choppe pas les script de /etc/init.d/ et donc la migration est parfois laborieuse, car il me manque des script pour ce nouvel init. donc j'ai des demons que je ne peux pas lancé. enfin pour le cas present.

----------

## Enlight

 *Quote:*   

> derniere question: vous avez un initrd au demarrage de votre gentoo?
> 
> je me rappelle, la premiere fois que je l avais installe, il y en avait un. mais apres, stage3, il etait pas marque dans la doc d en faire un, et a vrai dire, ca passe bien sans...
> 
> donc il s agirait de rajouter un initng, c est ca? 

 

Non!

l'initrd c'est un initial ramdisk, ça veut dire que grub va utiliser son driver de lecture des systèmes de fichiers pour charger ça en ram à une adresse précise à laquelle le kernel va la récupérer.

Basiquement tu as deux utilisations :

ton kernel est modulaire et n'a pas la capacité de lire ta partition /. Grub lui mets gentiement le module en ram afin qu'il le charge et puisse reprendre en montant /.

(2è solution, c'est une jolie n'image qui doit être affichée avant que le kernel ne puisse lire où elle se trouve dans le système d fichiers)

bref une fois que ta partition est visible pour le kernel, la première chose qu'il va faire c'est de lancer le programme spécifié dans ses options en tant que initrc= (de mémoire). Si l'option n'est pas explicitement spécifiée, il considère qu'elle vaut /sbin/init. (donc quand tu veux initng, ça doit être un truc genre initrc=/sbin/initng)

Quand /sbin/init est invoqué donc, il parcours le fichier /etc/inittab pour savoir quoi foutre. et en lisant ce fichiers on doit se rendre compte qu'il lance un script appelé rc (toujours de mémoire), qui est un scipt bash auquel il transmet l'argument du runlevel. C'est ce rc-script qui va invoquer tous les autres scripts situés dans /etc/init.d

Le truc, c'est qu'initng fait le boulot ET de /sbin/init ET du script rc, et comme on l'a vu le C ça va un poil plus vite que le bash, surtout quand on voit le morceau qu'est rc.

(si y'a des erreurs, merci de me corriger, tous les noms sont de tête donc c'est pas gagné)Last edited by Enlight on Tue Jan 24, 2006 11:02 am; edited 1 time in total

----------

## UB|K

@pathfinder:

mon avis est que c'est beaucoup moins compliqué d'installer un nouveau noyau et d'utiliser suspend2 plutôt que de passer à initng.

c'est à toi de voir, je te file 2 liens pour la route:

HOWTO Software Suspend v2

HOWTO Initng

----------

## KrysNux

Pour répondre au 1er post:

j'avais déjà chronométré le temps de démarrage entre grub et login console ~ 20 sec

Ma conf:

PIII 800

512 Mo de RAM.

Lancement parallèle.

D'un autre côté, ton problème vient peut etre du disque dur, jamais tres rapide sur les portables : 4200 tpm ou 5400 tpm, rarement 7200 tpm

Et un démarrage, c'est quasi que des accès disque.

Installation : depuis un stage 1, march=pentium3 -O2 -fomit-frame-pointer -pipe

De tete, car je ne suis pas chez moi

J'espère que j'ai pu aider

----------

## geekounet

 *Enlight wrote:*   

>  *pierreg wrote:*   Ben chez moi ça fait 50 sec avec sysvinit, et 15 avec initng   
> 
> Gnééééé???

 

Bon ben en fait quand j'ai fait 15 sec, je lancais pas tout ce que je lance avec sysvinit. Je viens de remesurer, ça me fait plutôt 30 sec, mais c déjà bien  :Smile: 

----------

## blorent

Ben je viens de chronométrer chez moi et j'arrive à + de 2minutes pour arriver dans E17 (avec login auto)....

J'utilise ni Software Suspend ni initng (vais y jeter un coup d'oeil à l'instant) ni ça pour l'instant mais je vois mal comment ça pourrait me faire descendre à des 20 secondes comme je vois que vous avez...

En gros je démarre avec un fbsplash (en silent depuis 1H), comme trucs particuliers je lance festival et speechd, j'ai un fallback pour eth0 qui prend 5 sec, je lance dbus et HAL, le tout sur un portable Celeron 2.5GHz avec 256Mb de SDRAM.

Des idées?

[EDIT]

Le résultat de rc-status boot : 

```
bootmisc                                                            [ started ]

 checkroot                                                           [ started ]

 consolefont                                                         [ started ]

 keymaps                                                             [ started ]

 modules                                                             [ started ]

 rmnologin                                                           [ started ]

 urandom                                                             [ started ]

 checkfs                                                             [ started ]

 clock                                                               [ started ]

 hostname                                                            [ started ]

 localmount                                                          [ started ]

 net.lo                                                              [ started ]

 serial                                                              [ started ]

 alsasound                                                           [ started ]

 splash                                                              [ started ]
```

----------

## geekounet

La question habituelle : as-tu le DMA pour ton disque dur ?

----------

## blorent

Je ne pense pas non.  Je peux vérifier ça comment? 

[RE-EDIT]Apparemment mon disque dur (20GB Ultra ATA/100 HDD) le supporte

----------

## blorent

Je confirme

```
/dev/hda:

 multcount    = 16 (on)

 IO_support   =  0 (default 16-bit)

 unmaskirq    =  0 (off)

 [color=red]using_dma    =  1 (on)[/color]

 keepsettings =  0 (off)

 readonly     =  0 (off)

 readahead    = 256 (on)

 geometry     = 16383/255/63, sectors = 39070080, start = 0

```

----------

## geekounet

Je voulais dire : est-ce que tu l'as activé dans ton kernel ?

Tu dois choisir le bon chipset dans "Device Drivers" => "ATA/ATAPI/MFM/RLL support" ...

Un lspci te donnera des infos sur ton chipset.

Cherche sur le forum, il y a pleins de discussion sur ce sujet ...

EDIT : un peu lent moi ...

Ça donne quoi hdparm -tT /dev/hda ?

----------

## blorent

Voilà

```
/dev/hda:

 Timing cached reads:   1288 MB in  2.05 seconds = 627.64 MB/sec

 Timing buffered disk reads:   48 MB in  3.02 seconds =  15.91 MB/sec

```

----------

## geekounet

15MB/s c'est pas beaucoup, tu ne dois pas avoir le bon support pour ton chipset, ou alors que le support générique.

Pour info, je boot en 1min sur mon laptop avec un DD 4200RPM (UATA/100 sur SATA) :

```
# hdparm -tT /dev/sda

/dev/sda:

 Timing cached reads:   2340 MB in  2.00 seconds = 1171.97 MB/sec

 Timing buffered disk reads:   80 MB in  3.02 seconds =  26.50 MB/sec

# rc-status boot

Runlevel: boot

 modules                                                            [ started  ]

 bootmisc                                                           [ started  ]

 localmount                                                         [ started  ]

 consolefont                                                        [ started  ]

 checkroot                                                          [ started  ]

 rmnologin                                                          [ started  ]

 clock                                                              [ started  ]

 checkfs                                                            [ started  ]

 hostname                                                           [ started  ]

 keymaps                                                            [ started  ]

 net.lo                                                             [ started  ]

 urandom                                                            [ started  ]

# rc-status default

Runlevel: default

 local                                                              [ started  ]

 netmount                                                           [ started  ]

 sshd                                                               [ started  ]

 net.eth0                                                           [ inactive ]

 alsasound                                                          [ started  ]

 gpm                                                                [ started  ]

 i8k                                                                [ started  ]

 cpufrequtils                                                       [ started  ]

 syslog-ng                                                          [ started  ]

 fcron                                                              [ started  ]

 acpid                                                              [ started  ]

 ntp-client                                                         [ started  ]

 mysql                                                              [ started  ]

 dbus                                                               [ started  ]

 hald                                                               [ started  ]

 xdm                                                                [ started  ]

 timidity                                                           [ started  ]

 net.eth2                                                           [ started  ]

```

Et sur mon vieux P3, je n'ai pas d'idée du temps de boot, par contre son DD de 40Go à 7400RPM :

```
# hdparm -tT /dev/hda

/dev/hda:

 Timing cached reads:   684 MB in  2.00 seconds = 342.07 MB/sec

 Timing buffered disk reads:  144 MB in  3.02 seconds =  47.70 MB/sec
```

----------

## blorent

Ah y'a un mieux (j'ai coché une option supplémentaire)

```
/dev/hda:

 Timing cached reads:   1364 MB in  2.10 seconds = 649.48 MB/sec

 Timing buffered disk reads:   80 MB in  3.00 seconds =  26.67 MB/sec

```

Et j'ai gagné un peu de temps au démarrage (mais ça reste assez long...).

Merci déjà, si t'as d'autres idées...

----------

## geekounet

C'est correct pour un DD de laptop, mais est-ce le cas ?

Sinon donne nous le résultat de lspci |grep IDE et ta config kernel concernant IDE (grep ^CONFIG_BLK_DEV /usr/src/linux/.config devrait suffire) pour vérifier que t'as bien mis ce qu'il faut.

----------

## blorent

Oui c'est bien un laptop.

Alors lspci |grep IDE : 

```
00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 03)
```

grep ^CONFIG_BLK_DEV /usr/src/linux/.config

```
CONFIG_BLK_DEV_FD=y

CONFIG_BLK_DEV_LOOP=y

CONFIG_BLK_DEV_CRYPTOLOOP=y

CONFIG_BLK_DEV_RAM=y

CONFIG_BLK_DEV_RAM_COUNT=16

CONFIG_BLK_DEV_RAM_SIZE=4096

CONFIG_BLK_DEV_INITRD=y

CONFIG_BLK_DEV_IDE=y

CONFIG_BLK_DEV_IDEDISK=y

CONFIG_BLK_DEV_IDECD=y

CONFIG_BLK_DEV_IDESCSI=y

CONFIG_BLK_DEV_CMD640=y

CONFIG_BLK_DEV_IDEPCI=y

CONFIG_BLK_DEV_GENERIC=y

CONFIG_BLK_DEV_RZ1000=y

CONFIG_BLK_DEV_IDEDMA_PCI=y

CONFIG_BLK_DEV_HPT34X=y

CONFIG_BLK_DEV_HPT366=y

CONFIG_BLK_DEV_PIIX=y

CONFIG_BLK_DEV_PDC202XX_OLD=y

CONFIG_BLK_DEV_PDC202XX_NEW=y

CONFIG_BLK_DEV_SIS5513=y

CONFIG_BLK_DEV_SLC90E66=y

CONFIG_BLK_DEV_TRM290=y

CONFIG_BLK_DEV_VIA82CXXX=y

CONFIG_BLK_DEV_IDEDMA=y

CONFIG_BLK_DEV_SD=y

CONFIG_BLK_DEV_SR=y

CONFIG_BLK_DEV_MD=m

CONFIG_BLK_DEV_DM=m

```

----------

## geekounet

Dans ce cas là, les perfs sont correctes  :Smile: 

Pour les chipsets, pour être sûr et faire plus propre, tu peux ne garder que Intel PIIXn chipsets support (CONFIG_BLK_DEV_PIIX), et désactiver les autres.

En gros, ça doit faire ça pour une config correcte :

```
<*> ATA/ATAPI/MFM/RLL support

<*>   Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support

<*>     Include IDE/ATA-2 DISK support

[*]     Use multi-mode by default

<*>     Include IDE/ATAPI CDROM support

<*>     generic/default IDE chipset support

[*]     PCI IDE chipset support

[*]       Sharing PCI IDE interrupts support

<*>       Generic PCI IDE Chipset Support          <-- pas sûr pour celui là, je l'ai et ça n'affecte pas les perfs, mais dans certains cas ça le fait, essaie en ne le mettant pas des fois que ...

[*]       Generic PCI bus-master DMA support

[*]         Use PCI DMA by default when available

<*>         Intel PIIXn chipsets support
```

----------

## blorent

Merci pour les infos.

En fait je viens d'activer Software Suspend 2  et ça me fait quand même passer à +/- 1 minute pour le démarrage... Sympa!  

Juste une dernière petite question, malgré SS2 ce qui prend le plus de temps c'est la partie "Loading Gentoo....." juste après l'écran de démarrage de Lilo (+/- 30 secondes alors que je vois que certains démarrent tout en 20 secondes   :Confused:  ), il n'y a t-il pas un moyen d'accéler ça (en fait je sais pas vraiment en quoi ça consiste ni ce que ça fait précisément   :Embarassed:  )

Merci beaucoup en tout cas.

----------

## geekounet

Tu veux dire le chargement du kernel juste après lilo ? Dans ce cas installe Grub ^^

----------

## blorent

C'est le début de la gestation d'un troll ou Grub est vraiment plus rapide?

----------

## geekounet

Les deux !!  :Mr. Green: 

Nan, mais je crois avoir déjà vu ce genre de pb avec lilo chez certaines personnes.

Essaie, on sait jamais  :Smile: 

----------

## BuBuaBu

Une autre technique pour amméliorer le temps de chargement du noyau consiste a passé un maximum de truc en modules et de les charger ensuite.

Avec initng en plus, le gain de vitesse est garantie.

----------

## geekounet

 *BuBuaBu wrote:*   

> Une autre technique pour amméliorer le temps de chargement du noyau consiste a passé un maximum de truc en modules et de les charger ensuite.
> 
> Avec initng en plus, le gain de vitesse est garantie.

 

Mais avec sysvinit, tu gagne rien au final, charger les modules après le noyau prends même légèrement plus de temps que s'il sont en dur ...

----------

