On peut aussi faire un démarrage comparatif en mode Verbose avec 4 puis 8 Go de RAM : system.log détaillera l'historique des démarrages.
Désactiver test RAM lors du Boot
- Créateur du sujet r e m y
- Date de début
POur ajouter à la confusion, comme j'avais un peu de temps aujourd'hui, j'ai passé ce MacBookPro de Lion à MountainLion.
Et bien maintenant cette phase de "booter" ne dure plus que 5 à 6 secondes (au lieu de 8...)
Je vais tester des démarrages en mode Verbose pour essayer de voir ce qu'il fait durant cette phase (dont j'imagine qu'elle se doit de durer un minimum de temps pour laisser le temps de presser les touches diverses et variées qu'il est susceptible d'intercepter à ce moment précis pour lancer le AHT ou démarrer sur une autre partition, ou sur le DVD...)
C'est toujours cmd-V à l'allumage pour activer le mode Verbose? (je crois que je ne l'ai pas activé depuis le passage des Macs PPC avec oPenFirmware aux Macs Intel avec EFI)
Et bien maintenant cette phase de "booter" ne dure plus que 5 à 6 secondes (au lieu de 8...)
Je vais tester des démarrages en mode Verbose pour essayer de voir ce qu'il fait durant cette phase (dont j'imagine qu'elle se doit de durer un minimum de temps pour laisser le temps de presser les touches diverses et variées qu'il est susceptible d'intercepter à ce moment précis pour lancer le AHT ou démarrer sur une autre partition, ou sur le DVD...)
C'est toujours cmd-V à l'allumage pour activer le mode Verbose? (je crois que je ne l'ai pas activé depuis le passage des Macs PPC avec oPenFirmware aux Macs Intel avec EFI)
Dernière édition:
C'est bien toujours Cmd+v.
Mais je ne suis pas certain qu'il y ait une différence dans le system.log avec ou sans Verbose
(Verbose affiche pendant le démarrage, c'est peut-être tout).
Mais je ne suis pas certain qu'il y ait une différence dans le system.log avec ou sans Verbose
(Verbose affiche pendant le démarrage, c'est peut-être tout).
J'ai grand plaisir à vous lire !
Par curiosité, j'ai fait le test avec mon iMac mid 2007 2.4 GHz Intel Core 2 duo 3 GB RAM et DD externe 7200 t/m connecté en FW 800 (mon DD interne est mort depuis longtemps !)
Résultats :
De l'allumage jusqu'au chime : 4s
Du chime jusqu'à l'écran avec pomme : 20s
De l'écran pommé jusqu'à ce que le bureau soit disponible : 48s
Soit 1 min et 12 s pour qu'il soit opérationnel ..... arghhhhhh !:eek:
Par curiosité, j'ai fait le test avec mon iMac mid 2007 2.4 GHz Intel Core 2 duo 3 GB RAM et DD externe 7200 t/m connecté en FW 800 (mon DD interne est mort depuis longtemps !
)Résultats :
De l'allumage jusqu'au chime : 4s
Du chime jusqu'à l'écran avec pomme : 20s
De l'écran pommé jusqu'à ce que le bureau soit disponible : 48s
Soit 1 min et 12 s pour qu'il soit opérationnel ..... arghhhhhh !:eek:
Bon ben j'ai fait les tests verbosités (effectivement ça ne change pas le niveau de détail des logs)
Aussi curieux que ça puisse paraître, avec 4 Go ou 8Go, il fait exactement la même chose jusqu'à l'affichage de la fenêtre de connexions (et à priori rien en rapport avec la RAM). Simplement, avec 8 Go, le début se fait plus lentement... pourtant il active le WiFi, se connecte au réseau WiFi, il active Find my Mac, il active le bluetooth, ... mais tout ça semble prendre plus de temps quand il y a 8 Go.
Aussi curieux que ça puisse paraître, avec 4 Go ou 8Go, il fait exactement la même chose jusqu'à l'affichage de la fenêtre de connexions (et à priori rien en rapport avec la RAM). Simplement, avec 8 Go, le début se fait plus lentement... pourtant il active le WiFi, se connecte au réseau WiFi, il active Find my Mac, il active le bluetooth, ... mais tout ça semble prendre plus de temps quand il y a 8 Go.
M
Membre supprimé 1060554
Invité
<Je dédie spécialement cette élucubration matutinale à l'euphorie de thebiglebowsky que cette conversation échevelée met en joie de lecture. En lui souhaitant donc un bon réveil avec cette tartine...>
remy - que le gain de 3" sur temps de 'Booter' grâce au passage de 10.7 à 10.8 ne peut qu'inciter à passer illico à Mac OS 10.9.4 (sic!) afin d'améliorer encore son score - peut donc être crédité d'une découverte que nous appellerons : le «Paradoxe_de_Rémy». Le «Paradoxe_de_Rémy» établit que : 'Plus il y a de RAM, plus ça RAME au démarrage' (je n'ose pas penser à ce que ça peut donner avec 32 Go de RAM! ). Sans que la fonction_mémoire de la RAM n'y soit pour rien, puisqu'aucune session d'utilisateur n'est encore ouverte.
Cet état de choses me fait penser au phénomène de l'inertie en Physique : plus un corps a de masse, plus il est difficile à ébranler (càd. à faire passer d'un état de repos à un état de mouvement, de par sa tendance naturelle à persister dans l'état actuel (par contre, une fois lancé, càd. animé d'une vitesse, il est d'autant plus difficile à arrêter de par sa tendance à persister dans son état de mouvement).
Puisque je suis bien parti ce matin pour abonder en considérations fumeuses, autant persister sur ma lancée, n'est-ce pas, en vertu du même phénomène d'inertie appliqué cette fois à la masse cérébrale (dont se tirerait la conjecture collatérale qu'un individu donné a d'autant plus de mal au démarrage matinal qu'il en a 'lourd sur la patate').
De ce point de vue, je trouve que l'intervention d'edd (dont je dois reconnaître qu'elle m'a plombé les méninges malgré sa brièveté) :
va complètement dans ce sens. De même la remarque de fousfous, si je lui emprunte l'attribut de «lenteur» mis en rapport avec la RAM.
Maintenant, ce qui aiguise le paradoxe est que ce 'ralentissement_au_démarrage' occasionné par la 'masse' de la RAM n'intervient pas sensiblement dans la phase 'EFI_Hardware' (si je puis me permettre ce raccourci = la phase de check-up délimitée par les 2 signaux : test du Super-Drive ⟺ Chime), mais dans la phase 'EFI_Booter' (pour me payer la même désinvolture scripturale = la phase de lancement délimitée par les 2 signaux : écran lumineux vide ⟺ écran lumineux pommé).
Les relevés d'opération résumés par remy d'après le mode 'auto-narratif' de démarrage paraissent montrer que le 'Booter' est multi-tâche pendant sa phase d'inititiative : sa mission n'est pas seulement de lancer le chargement du 'kernel' et des 'kexts', mais d'activer les connexions du Mac, avant cette tâche de lancement du chargement du noyau en tâche terminale. On comprend donc qu'il faille un 'certain temps' (même si ça se chiffre en un très petit nombre de secondes) au 'Booter' pour exécuter les tâches qui lui sont imparties.
Maintenant l'intéressant est le constat de remy (que je lui emprunte, me sentant trop en 'vacance' pour aller déchiffrer les lignes de logs restituant l'obscur côté de la force) que nulle part n'est signalé, pendant la phase d'activité du 'Booter', une tâche spéciale liée à la RAM.
C'est donc bien là que se joue le paradoxe de remy : la masse de la RAM, par un phénomène équivalant à l'inertie_physique, ralentit l'exécution des opérations du 'Booter' dans sa phase d'activité impartie (marquée par les 2 signaux limites : écran lumineux vide ⟺ écran lumineux pommé), sans pourtant que cela relève d'une tâche spécifique de ce même 'Booter' (évidemment, il y aurait dans les logs une ligne du type : 'pré-chauffage_RAM' - je plaisante- nous serions sauvés).
Nous sommes donc à la recherche d'une cause à la fois forcément présente et néanmoins invisible. Comme le dit si bien Sherlock Holmes : «Lorsque parmi toutes les hypothèses on a éliminé l'impossible, alors ce qui reste, si improbable que cela paraisse, doit être nécessairement vrai».
Il est peut-être intéressant ici de rappeler que le 'Booter' n'est pas un 'kernel', mais un fichier-relai (le fichier : boot-efi des 'CoreServices') exécuté par l'EFI (c'est avec le chargement du 'kernel' et des 'kexts' que l'EFI passe la main). Ce constat m'amène comme qui dirait sur un plateau un nouvelle conjecture (possiblement aussi fumeuse que ma précédente qui voulait que le 'Booter' s'en aille valider la 'sleepimage' entre autres tâches antédédant le chargement du 'kernel', et qui s'est avérée une 'idée en l'air') : à savoir, puisque c'est le Firmware qui opère du tout début du démarrage (signalé par le test du Super-Drive) à l'écran lumineux pommé (signalant l'enclenchement du chargement du 'kernel'), càd. pendant les 2 phases 'Check-up_Hardware' & 'Booter' - alors pourquoi ne pas supposer que l'EFI n'en a pas fini au signal du 'Chime' avec le 'Hardware'?
Ce serait donc sans attendre la complétion de sa tâche_Hardware (si je puis dire) que l'EFI déclencherait l'exécution du fichier 'Booter'. Il pourrait donc se faire que les opérations Firmware se divisent à l'instant signalé par le 'Chime', une opération consistant dans le sens de ce que edd déclarait à balayer les octets de la RAM et l'autre consistant à exécuter le fichier 'Booter' - ce, parallèlement, dans la phase où les tâches 'Booter' monopolisent l'avant-scène (donc : de l'écran lumineux vide à l'écran lumineux pommé). [La 'temporalité' exécutive du 'Booter' serait donc affectée par une 'soustraction d'énergie' due à la tâche de fond du Firmware regardant la RAM installée, sans qu'il s'agisse-là d'une tâche relevant du fichier exécutif boot.efi.]
♠
remy - que le gain de 3" sur temps de 'Booter' grâce au passage de 10.7 à 10.8 ne peut qu'inciter à passer illico à Mac OS 10.9.4 (sic!) afin d'améliorer encore son score
- peut donc être crédité d'une découverte que nous appellerons : le «Paradoxe_de_Rémy». Le «Paradoxe_de_Rémy» établit que : 'Plus il y a de RAM, plus ça RAME au démarrage' (je n'ose pas penser à ce que ça peut donner avec 32 Go de RAM! ). Sans que la fonction_mémoire de la RAM n'y soit pour rien, puisqu'aucune session d'utilisateur n'est encore ouverte. Cet état de choses me fait penser au phénomène de l'inertie en Physique : plus un corps a de masse, plus il est difficile à ébranler (càd. à faire passer d'un état de repos à un état de mouvement, de par sa tendance naturelle à persister dans l'état actuel (par contre, une fois lancé, càd. animé d'une vitesse, il est d'autant plus difficile à arrêter de par sa tendance à persister dans son état de mouvement).
Puisque je suis bien parti ce matin pour abonder en considérations fumeuses, autant persister sur ma lancée, n'est-ce pas, en vertu du même phénomène d'inertie appliqué cette fois à la masse cérébrale
(dont se tirerait la conjecture collatérale qu'un individu donné a d'autant plus de mal au démarrage matinal qu'il en a 'lourd sur la patate'). ♣
De ce point de vue, je trouve que l'intervention d'edd (dont je dois reconnaître qu'elle m'a plombé les méninges
malgré sa brièveté) :va complètement dans ce sens. De même la remarque de fousfous, si je lui emprunte l'attribut de «lenteur» mis en rapport avec la RAM.
Maintenant, ce qui aiguise le paradoxe est que ce 'ralentissement_au_démarrage' occasionné par la 'masse' de la RAM n'intervient pas sensiblement dans la phase 'EFI_Hardware' (si je puis me permettre ce raccourci = la phase de check-up délimitée par les 2 signaux : test du Super-Drive ⟺ Chime), mais dans la phase 'EFI_Booter' (pour me payer la même désinvolture scripturale = la phase de lancement délimitée par les 2 signaux : écran lumineux vide ⟺ écran lumineux pommé).
Les relevés d'opération résumés par remy d'après le mode 'auto-narratif' de démarrage
paraissent montrer que le 'Booter' est multi-tâche pendant sa phase d'inititiative : sa mission n'est pas seulement de lancer le chargement du 'kernel' et des 'kexts', mais d'activer les connexions du Mac, avant cette tâche de lancement du chargement du noyau en tâche terminale. On comprend donc qu'il faille un 'certain temps' (même si ça se chiffre en un très petit nombre de secondes) au 'Booter' pour exécuter les tâches qui lui sont imparties. Maintenant l'intéressant est le constat de remy (que je lui emprunte, me sentant trop en 'vacance' pour aller déchiffrer les lignes de logs restituant l'obscur côté de la force
) que nulle part n'est signalé, pendant la phase d'activité du 'Booter', une tâche spéciale liée à la RAM.♥
C'est donc bien là que se joue le paradoxe de remy : la masse de la RAM, par un phénomène équivalant à l'inertie_physique, ralentit l'exécution des opérations du 'Booter' dans sa phase d'activité impartie (marquée par les 2 signaux limites : écran lumineux vide ⟺ écran lumineux pommé), sans pourtant que cela relève d'une tâche spécifique de ce même 'Booter' (évidemment, il y aurait dans les logs une ligne du type : 'pré-chauffage_RAM' - je plaisante- nous serions sauvés).
Nous sommes donc à la recherche d'une cause à la fois forcément présente et néanmoins invisible. Comme le dit si bien Sherlock Holmes : «Lorsque parmi toutes les hypothèses on a éliminé l'impossible, alors ce qui reste, si improbable que cela paraisse, doit être nécessairement vrai».
♦
Il est peut-être intéressant ici de rappeler que le 'Booter' n'est pas un 'kernel', mais un fichier-relai (le fichier : boot-efi des 'CoreServices') exécuté par l'EFI (c'est avec le chargement du 'kernel' et des 'kexts' que l'EFI passe la main). Ce constat m'amène comme qui dirait sur un plateau un nouvelle conjecture (possiblement aussi fumeuse que ma précédente qui voulait que le 'Booter' s'en aille valider la 'sleepimage' entre autres tâches antédédant le chargement du 'kernel', et qui s'est avérée une 'idée en l'air') : à savoir, puisque c'est le Firmware qui opère du tout début du démarrage (signalé par le test du Super-Drive) à l'écran lumineux pommé (signalant l'enclenchement du chargement du 'kernel'), càd. pendant les 2 phases 'Check-up_Hardware' & 'Booter' - alors pourquoi ne pas supposer que l'EFI n'en a pas fini au signal du 'Chime' avec le 'Hardware'?
Ce serait donc sans attendre la complétion de sa tâche_Hardware (si je puis dire) que l'EFI déclencherait l'exécution du fichier 'Booter'. Il pourrait donc se faire que les opérations Firmware se divisent à l'instant signalé par le 'Chime', une opération consistant dans le sens de ce que edd déclarait à balayer les octets de la RAM et l'autre consistant à exécuter le fichier 'Booter' - ce, parallèlement, dans la phase où les tâches 'Booter' monopolisent l'avant-scène (donc : de l'écran lumineux vide à l'écran lumineux pommé). [La 'temporalité' exécutive du 'Booter' serait donc affectée par une 'soustraction d'énergie' due à la tâche de fond du Firmware regardant la RAM installée, sans qu'il s'agisse-là d'une tâche relevant du fichier exécutif boot.efi.]
♧
Dernière édition par un modérateur:
Devant ce paradoxe, je vais m'empresser de faire des tests de performance en fonctionnement normal de ce Mac avec 4 puis 8 Go de RAM installée.
Car peut-être ce constat effectué lors du démarrage est-il présent au quotidien sans que je m'en sois aperçu.
Peut-être ce MacBook Pro qu'Apple donne pour une capacité mémoire maximale de 4 Go mais qui, comme MacTracker l'a noté, reconnaît jusqu'à 8 Go fonctionne-t-il mieux avec 4 qu'avec 8 Go de RAM installée...
(ensuite j'irai faire des tests similaires sur mon iMac mid-2007 Core2Duo 2,4 MHz avec ses 4 Go de RAM car ce n'est pas tous les jours que TheBigLebowski intervient dans un forum technique. Je me sens donc comme un devoir de répondre à ses inquiétudes quant à la santé de son iMac en comparant ses performances avec celles que je relèverai sur le mien de mêmes caractéristiques)
Car peut-être ce constat effectué lors du démarrage est-il présent au quotidien sans que je m'en sois aperçu.
Peut-être ce MacBook Pro qu'Apple donne pour une capacité mémoire maximale de 4 Go mais qui, comme MacTracker l'a noté, reconnaît jusqu'à 8 Go fonctionne-t-il mieux avec 4 qu'avec 8 Go de RAM installée...
(ensuite j'irai faire des tests similaires sur mon iMac mid-2007 Core2Duo 2,4 MHz avec ses 4 Go de RAM car ce n'est pas tous les jours que TheBigLebowski intervient dans un forum technique. Je me sens donc comme un devoir de répondre à ses inquiétudes quant à la santé de son iMac en comparant ses performances avec celles que je relèverai sur le mien de mêmes caractéristiques)
M
Membre supprimé 1060554
Invité
Je remonte ce fil après m'être livré en coulisses à diverses investigations dont certaines historiques. Dont voici en résumé la «substantifique moëlle», comme disait le sieur Rabelais
:Les «Anciens Macs», entre 1983 et 1998, utilisaient pour démarrer une ROM (Read_Only_Memory) toute entière résidante dans une puce (chip) de la Carte Mère dénommée : Old World ROM, dont la caractéristique était qu'elle combinait le code de Bas_Niveau utilisé pour booter le hardware et le code de Haut_Niveau utilisé pour booter le Système d'Exploitation. La Old World ROM était donc un 'tout_en_un'.
Les «Macs Classiques», de 1998 à 2001, se mirent à utiliser pour démarrer une ROM 'répartie', si je puis dire, dénommée : New World ROM, ce qui signifie que la puce de la Carte-Mère n'abritait plus que le code de Bas-Niveau, appelé : «Boot-ROM» (ce qui s'est traduit par un rétrécissement notable de la taille du code), dont la fonction était de booter le hardware, tandis que le code de Haut-Niveau destiné à booter le Système d'exploitation était transféré au niveau logiciel sur le Disque sous forme de fichier 'Boot-Loader' dénommé : «Mac OS ROM».
Les «Macs Classiques» PPC supportant Mac OS X, de 2001 à 2006, héritiers de cette subdivision entre la Boot-ROM de la Carte-Mère et le Boot-Loader du disque, abritaient dans la puce de la Carte-Mère le code de Bas-Niveau utilisé pour démarrer le hardware (Boot-ROM) avec une implémentation Firmware appelée : 'Open_Firmware' ; tandis que le fichier-logiciel du disque abritant le code de Haut-Niveau destiné à démarrer le Système d'exploitation (= Boot-Loader), anciennement «Mac OS ROM» était remplacé par le fichier : «Boot-X».
Les «Mac Intels», à partir de 2006 donc, persévèrent dans cette subdivision de la structure de boot consistant en une Boot-ROM résidante dans une puce de la Carte-Mère et un Boot-Loader résidant sur le disque sous forme de fichier. La différence notable est que la Boot-ROM contenue dans la puce de la Carte-Mère combine désormais le code de Bas-Niveau chargé de démarrer le hardware (Boot-ROM stricto sensu) et une implémentation Firmware remplaçant l'ancien 'Open_Firmware' des Macs PPC dénommée : EFI (Extensible Firmware Interface) - cette combinaison dans la puce de la carte-mère portant le nom de : «EFI_Boot-ROM» ; par ailleurs, le fichier Boot-Loader résidant sur le disque, anciennement dénommé «Boot.X», est désormais le fichier : «Boot.efi» qu'on trouve à l'adresse : System/Library/CoreServices.
Les «Macs Classiques», de 1998 à 2001, se mirent à utiliser pour démarrer une ROM 'répartie', si je puis dire, dénommée : New World ROM, ce qui signifie que la puce de la Carte-Mère n'abritait plus que le code de Bas-Niveau, appelé : «Boot-ROM» (ce qui s'est traduit par un rétrécissement notable de la taille du code), dont la fonction était de booter le hardware, tandis que le code de Haut-Niveau destiné à booter le Système d'exploitation était transféré au niveau logiciel sur le Disque sous forme de fichier 'Boot-Loader' dénommé : «Mac OS ROM».
Les «Macs Classiques» PPC supportant Mac OS X, de 2001 à 2006, héritiers de cette subdivision entre la Boot-ROM de la Carte-Mère et le Boot-Loader du disque, abritaient dans la puce de la Carte-Mère le code de Bas-Niveau utilisé pour démarrer le hardware (Boot-ROM) avec une implémentation Firmware appelée : 'Open_Firmware' ; tandis que le fichier-logiciel du disque abritant le code de Haut-Niveau destiné à démarrer le Système d'exploitation (= Boot-Loader), anciennement «Mac OS ROM» était remplacé par le fichier : «Boot-X».
Les «Mac Intels», à partir de 2006 donc, persévèrent dans cette subdivision de la structure de boot consistant en une Boot-ROM résidante dans une puce de la Carte-Mère et un Boot-Loader résidant sur le disque sous forme de fichier. La différence notable est que la Boot-ROM contenue dans la puce de la Carte-Mère combine désormais le code de Bas-Niveau chargé de démarrer le hardware (Boot-ROM stricto sensu) et une implémentation Firmware remplaçant l'ancien 'Open_Firmware' des Macs PPC dénommée : EFI (Extensible Firmware Interface) - cette combinaison dans la puce de la carte-mère portant le nom de : «EFI_Boot-ROM» ; par ailleurs, le fichier Boot-Loader résidant sur le disque, anciennement dénommé «Boot.X», est désormais le fichier : «Boot.efi» qu'on trouve à l'adresse : System/Library/CoreServices.
♤
Nanti de ces quelques lueurs d'intelligence en ces obscures matières du 'commencement de toutes choses'
, je pense pouvoir revenir au «Paradoxe_de_Rémy» (précédemment invoqué pour constater que : 'Plus il y a de RAM installée, plus cela RAME au démarrage') pour clarifier peut-être davantage quelques maillons du processus de boot d'un Mac Intel supportant OS X.Si l'on prend en compte les signaux successifs qu'émet un tel Mac pendant ce processus global, voici en résumé les séquences que l'on peut distinguer :
- a) PHASE A : Du son de test du Super-Drive au Chime (carillon de démarrage) ;
- b) PHASE B : Du Chime au 1er écran Pomme ;
- c) PHASE C : Du 1er écran Pomme au 2è écran Pomme, séquence occupée par la rotation de la roue crantée ;
- d) PHASE D : Du 2è écran Pomme (avec cessation de la rotation de la roue crantée) à l'affichage de la Login Window (fenêtre de choix de session précédée immédiatement par l'affichage du pointeur).
- b) PHASE B : Du Chime au 1er écran Pomme ;
- c) PHASE C : Du 1er écran Pomme au 2è écran Pomme, séquence occupée par la rotation de la roue crantée ;
- d) PHASE D : Du 2è écran Pomme (avec cessation de la rotation de la roue crantée) à l'affichage de la Login Window (fenêtre de choix de session précédée immédiatement par l'affichage du pointeur).
Il semble bien que le problème constaté par remy intervienne pendant la PHASE B, càd. entre le retentissement du Chime et l'affichage du 1er écran Pomme. En fonction de la quantité de RAM installée (dans ses tests : une variation de 4 Go à 8 Go), il y aurait un allongement corrélatif de la durée de la PHASE B (sans qu'aucune option ne soit disponible pour réduire cette durée en cas de quantité de RAM installée élevée).
♧
Je crois pouvoir (à mes risques et périls, bien sûr, comme d'habitude dans ces sujets spéculatifs) interpréter ainsi les 4 phases signalées par le Mac lui-même pendant le processus de démarrage :
- a) PHASE A (soit du test Super-Drive au Chime) = POST (Power-On Self-Test), càd. vérification hardware brute réalisée par la Boot-ROM stricto sensu résidant dans la puce de la Carte-Mère ;
- b) PHASE B (soit du retentissement du Chime au 1er écran Pomme) = contrôle du démarrage passé de la Boot-ROM à l'EFI_Firmware qui implémente la puce de la Carte-Mère, EFI_Firmware qui exécute son programme propre (j'y reviens) ;
- c) PHASE C (soit du 1er écran Pomme au 2è écran Pomme : la séquence avec roue crantée) = exécution du Boot-Loader [le fichier du disque boot.efi] ;
- d) PHASE D (soit du 2è écran Pomme à la LoginWindow) = chargement du Kernel et des Extensions du noyau.
- b) PHASE B (soit du retentissement du Chime au 1er écran Pomme) = contrôle du démarrage passé de la Boot-ROM à l'EFI_Firmware qui implémente la puce de la Carte-Mère, EFI_Firmware qui exécute son programme propre (j'y reviens) ;
- c) PHASE C (soit du 1er écran Pomme au 2è écran Pomme : la séquence avec roue crantée) = exécution du Boot-Loader [le fichier du disque boot.efi] ;
- d) PHASE D (soit du 2è écran Pomme à la LoginWindow) = chargement du Kernel et des Extensions du noyau.
Il y aurait donc pendant le processus de démarrage d'un Mac Intel 2 phases de 'Bas-Niveau' et 2 phases de 'Haut-Niveau'.
♡
En ce qui concerne le processus de 'Bas-Niveau', le problème signalé par remy concerne sa phase 2 : le moment où l'EFI prend la main pour exécuter ses propres tâches. En quoi consistent ces tâches? Eh bien précisément dans l'initialisation de la RAM, de la MMU (Memory Management Unit), dans la vérification des paramètres stockés en NVRAM <c'est là qu'en cas de choix de l'hibernation, le paramètre de re-démarrage sur la sleep-image stocké en NVRAM est lu par l'EFI, ce qui change la suite de la séquence de démarrage> et la construction d'un DEVICE-TREE = arbre de connexion des engins périphériques.
Si cette interprétation est valide, nul doute que l'initialisation de la RAM par l'EFI pendant cette phase ne prenne une durée variant proportionnellement avec la quantité de RAM installée - ce que edd, je le rappelle, avait directement diagnostiqué. Le «Paradoxe_de_Remy» serait donc résolu, avec ses dommages collatéraux : impossibilité d'agir sur la durée de cette phase de Bas-Niveau impartie à l'EFI. Le seul aspect 'paradoxal' demeurant pour l'imagination le contaste entre une augmentation de la RAM censée éviter un étirement en longueur des processus et cet étirement même, contraste qui se résout en constatant qu'il ne s'agit pas des mêmes laps de temps : démarrage d'un côté, utilisation dans une session active de l'autre [or c'est le propre de l'imagination, comme instrument de fictionnement d'une satisfaction des désirs, d'ignorer la 'résistance du réel' pour lui substituer la 'plasticité de l'irréel' ainsi que la 'différence des temps' pour la remplacer par les 'court-circuits de l'intemporel'. D'où le désir de bénéficier tout de suite de la RAM avant même que la mise à disposition de la RAM ne soit devenue effective...]
Pour ce qui est des processus de 'Haut-Niveau' qui s'ensuivent, je crois qu'il convient de noter que le Boot-Loader du disque (= 'boot.efi') peut être considéré comme une «Application_de_l'EFI». C'est l'EFI qui enclenche l'exécution du Boot-Loader, lequel, dans sa phase propre (= PHASE C) qui va du 1er écran Pomme au 2è avec rotation de la roue crantée, configure le clavier, distribue la mémoire à diverses tâches et vérifie si aucune touche de clavier n'est pressée (de manière à enclencher ou non le 'Verbose' mode, ou 'Single-User' mode par exemple), avant de lancer le chargement du kernel.
♢
Dernière édition par un modérateur:
ah ben mince! moi qui pensait avoir mis le doigt sur un nouveau paradoxe et consacrer ma future retraite à publier des bouquins et faire des conférences (rémunérées) sur ce "paradoxe de remy"...
Telle Perrette, me voici devant mon pot au lait brisé
Telle Perrette, me voici devant mon pot au lait brisé
M
Membre supprimé 1060554
Invité
LOL.
Il demeure un «Paradoxe-de_Rémy» - du point-de-vue de l'UTILISATEUR (celui qui veut 'tout_tout de suite', ce qui doit se faire cruellement sentir pour quelqu'un qui possède 32 Go de RAM + un SSD, et qui doit attendre lamentablement le nombre de secondes augmenté qu'il faut à l'EFI pour initialiser justement une RAM de taille augmentée) ; mais pas du point-de-vue du SYSTÈME (lequel agit en conformité avec la 'logique' des choses, si je puis dire).
- Édit. Tout ce qui précède m'a mis en veine de facéties - sans lesquelles ces graves élucubrations auraient bien du mal à ne pas laisser un goût quelque peu amer
Il demeure un «Paradoxe-de_Rémy» - du point-de-vue de l'UTILISATEUR (celui qui veut 'tout_tout de suite', ce qui doit se faire cruellement sentir pour quelqu'un qui possède 32 Go de RAM + un SSD, et qui doit attendre lamentablement
le nombre de secondes augmenté qu'il faut à l'EFI pour initialiser justement une RAM de taille augmentée) ; mais pas du point-de-vue du SYSTÈME (lequel agit en conformité avec la 'logique' des choses, si je puis dire).- Édit. Tout ce qui précède m'a mis en veine de facéties - sans lesquelles ces graves élucubrations auraient bien du mal à ne pas laisser un goût quelque peu amer
Il me revient une furieuse anecdote concernant le notoire Immanuel Kant, un homme qui faisait tout par raison au cours de ses journées réglées d'après un emploi du temps immuable, lever à 5H, coucher à 19H, promenade toujours identique dans Königsberg aux mêmes heures de l'après-midi, repas de midi avec des invités de sa bonne ville dont le nombre devait toujours être compris entre celui des Grâces, c'est-à-dire jamais inférieur à 3, et celui des Muses, c'est-à-dire jamais supérieur à 9 - j'en passe, et des meilleures.
Bien. Ledit Kant employait comme homme à tout faire un domestique nommé Lampe qui lui préparait et servait ses repas. Au moment du café, dont Kant raffolait, on rapporte que notre philosophe qui, ne supportant pas que le café soit préparé de serait-ce que 5 minutes à l'avance , le voulait absolument frais, ne tolérait néanmoins pas la moindre durée d'attente entre la profération de son ordre : 'Café!' (à la Prussienne, comme il se doit, à son employé ancien militaire porteur du casque à pointe) et l'arrivée dudit café à sa table. Il passait donc tout le temps qu'il fallait à son domestique pour le préparer à glapir d'une voie de crécelle en trépignant des pieds comme un gosse capricieux : «Café! Café! Café!...» sans pouvoir se contrôler
On peut dire qu'il était prisonnier à sa façon du paradoxe qu'il y a à désirer tout de suite l'usage de quelque chose qui demande du temps à se faire. Comme le remarque perfidement Henri Bergson après coup : en plus, il lui fallait une fois le café présenté attendre que le sucre fonde...
Le «Paradoxe de Rémy», qui est un paradoxe SUBJECTIF (et non pas 'OBJECTIF'), aurait très bien pu affecter le sieur Kant pour peu qu'il ait vécu à une époque ultérieure. Supposons, en effet, que pour raccourcir la durée de confection du café pendant laquelle il glapissait : «Café! Café!» dans son désir d'avoir tout de suite ce qui demandait du temps à se faire, Kant se soit acheté une cafetière électronique dont la vitesse d'opérations eût demandé un temps de chargement logiciel préalable. Il aurait pu glapir ; «Café! Café!» tout le temps que sa cafetière électronique chargeait ses programmes avant de procéder à ses opérations. Supposons encore le même Kant en possession d'un Mac avec SSD dernier cri et 32 Go de RAM : je l'imagine d'ici glapissant à son bureau en trépignant des 2 pieds : «FINDER! FINDER!» tout le temps du boot de son Mac - notoirement rallongé dans la phase B par l'initialisation des 32 Go de RAM par l'EFI. On peut combiner les 2 scénarios et imaginer Kant lançant simultanément son Mac et sa machine à café électronique et glapissant alternativement : «Finder! Café! Finder! Café!» Je signale pour finir que son pavé : la «Critique de la raison Pure» examine précisément dans son final des «Paradoxes de la Raison» qui, dans les cas ici convoqués, seraient bien mieux considérés comme des «Paradoxes de la Faculté de Désirer»...
Bien. Ledit Kant employait comme homme à tout faire un domestique nommé Lampe qui lui préparait et servait ses repas. Au moment du café, dont Kant raffolait, on rapporte que notre philosophe qui, ne supportant pas que le café soit préparé de serait-ce que 5 minutes à l'avance , le voulait absolument frais, ne tolérait néanmoins pas la moindre durée d'attente entre la profération de son ordre : 'Café!' (à la Prussienne, comme il se doit, à son employé ancien militaire porteur du casque à pointe) et l'arrivée dudit café à sa table. Il passait donc tout le temps qu'il fallait à son domestique pour le préparer à glapir d'une voie de crécelle en trépignant des pieds comme un gosse capricieux : «Café! Café! Café!...» sans pouvoir se contrôler
On peut dire qu'il était prisonnier à sa façon du paradoxe qu'il y a à désirer tout de suite l'usage de quelque chose qui demande du temps à se faire. Comme le remarque perfidement Henri Bergson après coup : en plus, il lui fallait une fois le café présenté attendre que le sucre fonde...
Le «Paradoxe de Rémy», qui est un paradoxe SUBJECTIF (et non pas 'OBJECTIF'), aurait très bien pu affecter le sieur Kant pour peu qu'il ait vécu à une époque ultérieure. Supposons, en effet, que pour raccourcir la durée de confection du café pendant laquelle il glapissait : «Café! Café!» dans son désir d'avoir tout de suite ce qui demandait du temps à se faire, Kant se soit acheté une cafetière électronique dont la vitesse d'opérations eût demandé un temps de chargement logiciel préalable. Il aurait pu glapir ; «Café! Café!» tout le temps que sa cafetière électronique chargeait ses programmes avant de procéder à ses opérations. Supposons encore le même Kant en possession d'un Mac avec SSD dernier cri et 32 Go de RAM : je l'imagine d'ici glapissant à son bureau en trépignant des 2 pieds : «FINDER! FINDER!» tout le temps du boot de son Mac - notoirement rallongé dans la phase B par l'initialisation des 32 Go de RAM par l'EFI. On peut combiner les 2 scénarios et imaginer Kant lançant simultanément son Mac et sa machine à café électronique et glapissant alternativement : «Finder! Café! Finder! Café!»
Je signale pour finir que son pavé : la «Critique de la raison Pure» examine précisément dans son final des «Paradoxes de la Raison» qui, dans les cas ici convoqués, seraient bien mieux considérés comme des «Paradoxes de la Faculté de Désirer»...
Dernière édition par un modérateur:
mais je me demande si certains marketeurs n'ont pas déjà intégré ce paradoxe de la faculté de désirer!
En effet j'ai en mémoire une pub pour un appareil photo numérique (dont j'ai oublié la marque) dont l'argumentaire résidait justement dans sa capacité à déclencher la prise de vue avant même qu'on n'ait appuyé sur le déclencheur et donc avant même qu'on ait eu l'idée ou le désir de prendre la photo pour satisfaire ce désir à l'instant même où il se manifeste sans aucun délai.
Un peu comme si le majordome de Kant avait été en mesure d'anticiper précisément sur l'apparition du désir de café de son prussien de maître pour en lancer la préparation de façon à ce qu'il finisse de passer exactement lors de la première émission de l'ordre "café"!
Apple pourrait intégrer cette capacité prédictive à ses Macs pour que ceux-ci démarrent avant même qu'on ait appuyé sur le bouton d'allumage et permettre à l'EFI d'initialiser la RAM en temps masqué permettant alors de satisfaire le désir d'allumage instantanément
En effet j'ai en mémoire une pub pour un appareil photo numérique (dont j'ai oublié la marque) dont l'argumentaire résidait justement dans sa capacité à déclencher la prise de vue avant même qu'on n'ait appuyé sur le déclencheur et donc avant même qu'on ait eu l'idée ou le désir de prendre la photo pour satisfaire ce désir à l'instant même où il se manifeste sans aucun délai.
Un peu comme si le majordome de Kant avait été en mesure d'anticiper précisément sur l'apparition du désir de café de son prussien de maître pour en lancer la préparation de façon à ce qu'il finisse de passer exactement lors de la première émission de l'ordre "café"!
Apple pourrait intégrer cette capacité prédictive à ses Macs pour que ceux-ci démarrent avant même qu'on ait appuyé sur le bouton d'allumage et permettre à l'EFI d'initialiser la RAM en temps masqué permettant alors de satisfaire le désir d'allumage instantanément
Apple est plus prosaïque = http://support.apple.com/kb/HT2674?viewlocale=fr_FR
Et les Mac OS X Support Essential comme Guillaume Gete plus prolixes dans leurs livres,
où ils détaillent des processus et des éléments sur plusieurs pages. Si ça t'intéresse.
Bonjour,
Je viens de tomber sur ce post passionnant (et complexe pour moi), après avoir ragé une nouvelle fois en attendant l'affichage de la pomme sur mon Mac Mini SSD : il se passe 2 fois plus de temps entre le démarrage et l'affichage de la pomme que pour le chargement de l'OS.
Toujours pas moyen de diminuer ce moment de flottement ?
Je viens de tomber sur ce post passionnant (et complexe pour moi), après avoir ragé une nouvelle fois en attendant l'affichage de la pomme sur mon Mac Mini SSD : il se passe 2 fois plus de temps entre le démarrage et l'affichage de la pomme que pour le chargement de l'OS.
Toujours pas moyen de diminuer ce moment de flottement ?
M
Membre supprimé 1060554
Invité
Salut bazino.
Pfuiii ! - Ç'avait chauffé dans la "conjecture en longitude" dans ce fil...
L'affichage de la signe le fait que le fichier démarreur de l'OS (le boot_loader : boot.efi at: /System/Library/CoreServices/boot.efi) vient d'être exécuté par le Programme Interne du Mac (aka: l'EFI). 2 facteurs peuvent rendre compte d'un délai exagéré entre l'allumage du Mac et l'exécution du boot_loader signalé par la :
L'affichage de la signe le fait que le fichier démarreur de l'OS (le boot_loader : boot.efi at: /System/Library/CoreServices/boot.efi) vient d'être exécuté par le Programme Interne du Mac (aka: l'EFI). 2 facteurs peuvent rendre compte d'un délai exagéré entre l'allumage du Mac et l'exécution du boot_loader signalé par la :
- a) soit le processus initial de la vérification_hardware par l'EFI traîne en longueur suite à un rajout de RAM (c'était le sujet de ce fil qui avait débouché sur l'invention du «Paradoxe de Rémy»
)
- b) soit plus banalement aucun chemin en NVRAM (mémoire statique de la Carte-Mère que visite l'EFI) n'est mentionné au fichier boot_loader : boot.efi à exécuter automatiquement sur la partition /dev/disk0s2 de l'OS --> l'EFI est donc obligée de lancer le programme auxiliaire DiskManager (un gestionnaire de démarrage natif) en coulisses, pour lui faire scanner tous les volumes montés à la recherche d'un fichier boot.efi exécutable et... ça prend le temps qu'il faut avant que le DiskManager retourne une adresse valide après enquête exhaustive.
☞ Dans ce dernier cas, toute cette tergiversation initiale est supprimée en allant, depuis la session ouverte, à : Menu /Préférences Système/Disque de démarrage. Si tu es sous «El Capitan», il faut désormais cliquer le cadenas en bas à gauche et s'authentifier avec un mot-de-passe admin pour pouvoir agir dans ce panneau. Tu sélectionnes le volume affiché de ton OS et ça suffit. Pas besoin de re-démarrer dans la foulée : ta sélection est une action graphique qui déclenche en coulisses l'écriture en NVRAM d'un chemin de boot automatique au fichier : /System/Library/CoreServices/boot.efi sur la partition /dev/disk0s2 de l'OS --> tu vas bien voir à ton prochain démarrage si la s'affiche illico presto où si continue de traîner avant affichage.
- b) soit plus banalement aucun chemin en NVRAM (mémoire statique de la Carte-Mère que visite l'EFI) n'est mentionné au fichier boot_loader : boot.efi à exécuter automatiquement sur la partition /dev/disk0s2 de l'OS --> l'EFI est donc obligée de lancer le programme auxiliaire DiskManager (un gestionnaire de démarrage natif) en coulisses, pour lui faire scanner tous les volumes montés à la recherche d'un fichier boot.efi exécutable et... ça prend le temps qu'il faut avant que le DiskManager retourne une adresse valide après enquête exhaustive.
☞ Dans ce dernier cas, toute cette tergiversation initiale est supprimée en allant, depuis la session ouverte, à : Menu /Préférences Système/Disque de démarrage. Si tu es sous «El Capitan», il faut désormais cliquer le cadenas en bas à gauche et s'authentifier avec un mot-de-passe admin pour pouvoir agir dans ce panneau. Tu sélectionnes le volume affiché de ton OS et ça suffit. Pas besoin de re-démarrer dans la foulée : ta sélection est une action graphique qui déclenche en coulisses l'écriture en NVRAM d'un chemin de boot automatique au fichier : /System/Library/CoreServices/boot.efi sur la partition /dev/disk0s2 de l'OS --> tu vas bien voir à ton prochain démarrage si la s'affiche illico presto où si continue de traîner avant affichage.
Sujets similaires
