MacBook Pro Eteindre macbook à chaque déplacement?
- Créateur du sujet e_lpt
- Date de début
M
Membre supprimé 1060554
Invité
Je remets le tableau des paramètres de l'alimentation sur batterie sur cette page pour qu'on l'ait sous les yeux -->
L'« autopoweroff » est l'effet d'une norme purement européenne d'économie d'énergie > dont l'activation amène le kernel (noyau du Système) à "semi-hiberner" passé un laps de temps de sommeil simple (sleep) donné par la valeur de l'« autopoweroffdelay ». Ici égale à 28800 secondes = 480 minutes = 8 heures.
Ce paramétrage mérite d'être court-circuité > dans la mesure où il s'agit d'une instruction parasite du paramétrage natif du « standby » - lequel est une règle de passage du kernel (noyau du Système) à l'hibernation passé un délai déterminé de sommeil simple (= sleep). Pour les Mac récents > il existe 2 paramètres temporels de « standbydelay » : délai temporel en secondes passé lequel le kernel vire du sommeil simple (= sleep) à l'hibernation (= standby) -->
Ici le « standbydelaylow » a une valeur de 10800 secondes = 180 minutes = 3 heures ; et le « standbydelayhigh » a une valeur de 86400 secondes = 1440 minutes = 24 heures. Des valeurs absurdes, bien sûr.
Bloc de code:
Battery Power:
lidwake 1
autopoweroff 1
standbydelayhigh 86400
autopoweroffdelay 28800
standbydelaylow 10800
standby 1
ttyskeepawake 1
hibernatemode 3
powernap 0
gpuswitch 2
hibernatefile /var/vm/sleepimage
proximitywake 0
highstandbythreshold 50
displaysleep 2
sleep 1
tcpkeepalive 1
halfdim 1
acwake 0
lessbright 1
disksleep 10L'« autopoweroff » est l'effet d'une norme purement européenne d'économie d'énergie > dont l'activation amène le kernel (noyau du Système) à "semi-hiberner" passé un laps de temps de sommeil simple (sleep) donné par la valeur de l'« autopoweroffdelay ». Ici égale à 28800 secondes = 480 minutes = 8 heures.
Ce paramétrage mérite d'être court-circuité > dans la mesure où il s'agit d'une instruction parasite du paramétrage natif du « standby » - lequel est une règle de passage du kernel (noyau du Système) à l'hibernation passé un délai déterminé de sommeil simple (= sleep). Pour les Mac récents > il existe 2 paramètres temporels de « standbydelay » : délai temporel en secondes passé lequel le kernel vire du sommeil simple (= sleep) à l'hibernation (= standby) -->
- le « standbydelaylow » : le délai temporel avant mise en standby de type "bas" = pris en compte si (et seulement si) la charge de la batterie est de 50% ou en-dessous de la charge maximale au moment de l'opération.
- le « standbydelayhigh » : le délai temporel avant mise en standby de type "haut" = pris en compte si (et seulement si) la charge de la batterie est supérieure à 50% de la charge maximale au moment de l'opération.
Ici le « standbydelaylow » a une valeur de 10800 secondes = 180 minutes = 3 heures ; et le « standbydelayhigh » a une valeur de 86400 secondes = 1440 minutes = 24 heures. Des valeurs absurdes, bien sûr.
M
Membre supprimé 1060554
Invité
Parce qu'un utilisateur nomade a tout intérêt à ce que son Mac portable > après mise en sommeil simple (= sleep) par le rabat du couvercle à la volée > passe le plus vite possible à l'état d'hibernation du kernel -->
En conséquence de ces condidérations byzantines --> l'utilisateur nomade a tout intérêt à tabler sur un virage à l'hibernation le plus court possible en délai après le rabat du couvercle.
- en voici la raison exacte : avec le choix classique pour un portable sur batterie d'un « hibernatemode 3 » --> lors de la mise en sommeil simple du kernel (= sleep) au rabat du couvercle > la RAM se trouve maintenue sous tension tout le temps du sommeil (sleep) afin que le contexte de la RAM reste disponible instantanément en cas de réveil direct depuis le sleep (ré-ouverture du couvercle). Or le maintien sous tension de la RAM consomme forcément de la batterie. Un utilisateur nomade a tout intérêt à ce que le kernel passe le plus vite possible à l'état d'hibernation après le rabat du couvercle (càd. à ce que le délai de sommeil simple soit le plus court possible) > car l'hibernation implique nécessairement la désactivation de la RAM - ce qui fait donc économiser de l'énergie de la batterie.
- afin de pallier la perte du contexte de la RAM suite à sa désactivation lors du passage sleep => standby --> le contexte de la RAM est écrit à un fichier du disque appelé sleepimage - fichier stocké dans le format apfs dans un volume auxiliaire VM (Virtual Memory) monté automatiquement dans le volume de démarrage at: /private/var/vm. Le contexte de la RAM sauvegardé à la sleepimage > la RAM peut être désactivée et le kernel viré à l'hibernation --> lors du réveil du kernel de l'hibernation > le contexte de la RAM se trouve reconstitué d'après la sleepimage --> ce qui implique un temps de réveil un peu plus long que si la RAM avait été maintenue sous tension > mais délai compensé par le gain de dépense d'énergie dû à la désactivation de la RAM pendant le standby.
En conséquence de ces condidérations byzantines --> l'utilisateur nomade a tout intérêt à tabler sur un virage à l'hibernation le plus court possible en délai après le rabat du couvercle.
M
Membre supprimé 1060554
Invité
Et c'est là qu'un amusant paradoxe intervient -->
Évidemment chez toi une valeur comme 24 heures pour le « standbydelayhigh » est assez hilarante > car le standby n'intervient jamais par principe au rabat du couvercle.
En résumé de ces élucubrations > il ne serait pas mauvais de tester le paramétrage suivant :
Ainsi on aurait la situation paradigmatique suivante :
=> tu n'as qu'à dire ce que tu penses de scénario (évidemment modulable). Une commande pmset de paramétrage > se bornant à écrire à un fichier at: /Library/Preferences/com.apple.PowerManagement.plist - écritures éditables à souhait par une autre commande.
- ledit utilisateur qui vise à minimiser la consomation de sa batterie > va donc se situer « théoriquement » dans un cas de figure standard où il se trouve en-dessus de 50% de charge de celle-ci --> ce que j'appellerais la situation « d'attaque » d'une journée. Or la batterie se situant à + 50 % de charge > c'est le « standbydelayhigh » qui va être uniquement pris en charge comme plage d'attente du sommeil simple (= sleep) avant le virage à l'hibernation. Et pas le « standbydelaylow » qui ne détermine un délai valide que pour une situation en-dessous des 50% de charge de la batterie.
- il s'ensuit nécessairement que le « standbydelayhigh » ne doit jamais être supérieur au « standbydelaylow (contrairement à ce que les mots inclinent l'entendement à s'imaginer) > car c'est sur le délai temporel du « standbydelayhigh » que l'utilisateur nomade va fonctionner dès l'« attaque » matutinale de sa journée et pendant toute sa première partie décisive en économie de batterie. Il faut donc que le « standbydelayhigh » détermine un temps de sommeil simple (= sleep) passé lequel il y a virage à l'hibernation (= standby) le plus court possible --> afin d'éviter que le RAM ne soit maintenue sous tension sur la charge de la batterie. Le « standbydelaylow » pouvant alors être égal à ce « standbydelayhigh » minimaliste.
Évidemment chez toi une valeur comme 24 heures pour le « standbydelayhigh » est assez hilarante > car le standby n'intervient jamais par principe au rabat du couvercle.
En résumé de ces élucubrations > il ne serait pas mauvais de tester le paramétrage suivant :
- autopoweroff = 0 (désactivation) > standby = 1 (activation) > standbydelayhigh (valeur normale) = 300 (secondes = 5 minutes de sommeil simple ou sleep) > displaysleep = 2 minutes (en cas de non rabat du couvercle - lequel sinon précipite le sommeil de l'écran) > disksleep = 2 minutes (en cas de non rabat du couvercle - - lequel sinon précipite le sommeil du disque) > sleep = 3 minutes (en cas de non rabat du couvercle - - lequel sinon précipite le sommeil du kernel)
Ainsi on aurait la situation paradigmatique suivante :
- Mac couvercle ouvert sans action dans la session : 2 minutes de délai avant sommeil de l'écran et du disque et 3 minutes de délai avant sommeil du kernel (sleep) automatique. En cas de rabat du couvercle => précipitation simultanée de : sommeil écran > sommeil disque > sommeil kernel (le sleep débutant dès ce rabat). Alors 300 secondes = 5 minutes après ce rabat du couvercle > il y aurait en situation normale virage au standby = écriture du contexte de la RAM à la sleepimage du volume VM > désactivation de la RAM > passage du kernel à l'hibernation de ses fonctions (standby). Ce qui minimise la consommation de batterie (théoriquement et sans bogue du Système installé). Au relèvement du couvercle > court délai de reconstruction du contexte de la RAM d'après la sleepimage et récupération de la session (toujours théoriquement = sans bogue du Système installé).
=> tu n'as qu'à dire ce que tu penses de scénario (évidemment modulable). Une commande pmset de paramétrage > se bornant à écrire à un fichier at: /Library/Preferences/com.apple.PowerManagement.plist - écritures éditables à souhait par une autre commande.
Dernière édition par un modérateur:
Salut vieux fou ...
Super clair ... comme d'hab
Bon ... donc ça revient à reparamétrer avec autre chose que les pieds d' ... J'suis partant pour utiliser les mains.
Peux tu me refiler la commande qui va appliquer tes nouveaux paramètres qui me paraissent absolument d'une logique implacable !
Merci vieille branche !
Edit : A la lumière de tes éclaircissements, il apparait évident que leur choix de paramétrage par défaut en manque de lumière ... c'est même assez obscur comme logique ... :meh:
Super clair ... comme d'hab
Bon ... donc ça revient à reparamétrer avec autre chose que les pieds d' ... J'suis partant pour utiliser les mains.
Peux tu me refiler la commande qui va appliquer tes nouveaux paramètres qui me paraissent absolument d'une logique implacable !
Merci vieille branche !
Edit : A la lumière de tes éclaircissements, il apparait évident que leur choix de paramétrage par défaut en manque de lumière ... c'est même assez obscur comme logique ... :meh:
M
Membre supprimé 1060554
Invité
Passe la commande (copier-coller) :
La commande passée (sans commentaire) > redémarre une fois pour que l'édition du fichier com.apple.powermanagement.plist soit chargée par le kernel.
=> c'est expérimental. Éditable pour partie ou tout. Peut-être trop radical (délais trop brefs). Tu verras bien.
Bloc de code:
sudo pmset -b autopoweroff 0 standby 1 standbydelayhigh 300 standbydelaylow 300 displaysleep 2 disksleep 2 sleep 3- à validation > une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe de session admin en aveugle - aucun caractère ne se montrant à la frappe - et revalide
- la commande désactive l'autopoweroff > maintient activé le standby avec un délai (haut = bas) de 5 minutes de déclenchement après le début du sommeil du kernel > détermine une mise-en-sommeil automatique après 2 minutes d'inactivité en session pour écran & disque et 3 minutes pour le kernel. Sinon > le rabat du couvercle enclenche instantanément ce triple sommeil > et c'est donc 5 minutes après qu'intervient l'hibernation
La commande passée (sans commentaire) > redémarre une fois pour que l'édition du fichier com.apple.powermanagement.plist soit chargée par le kernel.
=> c'est expérimental. Éditable pour partie ou tout. Peut-être trop radical (délais trop brefs). Tu verras bien.
@macomaniac ... grand manitou ...
Franchement, le temps de sortie de veille me va niquel ... m'reste plus qu'à laisser la bécane toute la nuit comme ça et j'te dis demain matin.
Franchement, le temps de sortie de veille me va niquel ... m'reste plus qu'à laisser la bécane toute la nuit comme ça et j'te dis demain matin.
M
Membre supprimé 1060554
Invité
Content pour toi !
- c'est l'effet de l'hibernation (= standby).
- tu n'auras qu'à dire par contre si > couvercle laissé ouvert > des délais de 2 minutes avant obscurcissement écran & sommeil disque > et de 3 minutes avant sommeil du kernel --> ne sont pas un peu trop courts pour être confortables en pratique.
- inversement > il serait possible d'être encore plus radical comme délai de standby (temps de sommeil du kernel après lequel il y a hibernation) : genre 3 minutes.
Écoute ... au lever du couvercle; il se passe 2 secondes pour qu’il se réactive.
Ça me va très bien.
Pour l’obscurcissement ... tant qu’il ne s’active pas en plein taf !
Ça me va très bien.
Pour l’obscurcissement ... tant qu’il ne s’active pas en plein taf !
Dernière édition:
bonjour,
j'ai un MBA 2017 (Mojave) depuis 1 mois et depuis 10 jours j'ai également la batterie qui perd 20% la nuit, en veille...avant c'étai juste qlq % en moins.
j'ai bien lu le topic et j'ai appliqué le script de Macromaniac (merci pour les explications) en l'assouplissant un peu :
sudo pmset -b autopoweroff 0 standby 1 standbydelayhigh 900 standbydelaylow 900 displaysleep 5 disksleep 5 sleep 10
résultat après 24h de veille : -35%...pas satisfaisant.
Y a t il autre chose à faire ou ces valeurs ne sont pas assez strictes ? ou bien est ce pour un MBP et pas pour un MBA ?
j'avais les mêmes valeurs que Bartolomero après un -gcustom.
j'ai un MBA 2017 (Mojave) depuis 1 mois et depuis 10 jours j'ai également la batterie qui perd 20% la nuit, en veille...avant c'étai juste qlq % en moins.
j'ai bien lu le topic et j'ai appliqué le script de Macromaniac (merci pour les explications) en l'assouplissant un peu :
sudo pmset -b autopoweroff 0 standby 1 standbydelayhigh 900 standbydelaylow 900 displaysleep 5 disksleep 5 sleep 10
résultat après 24h de veille : -35%...pas satisfaisant.
Y a t il autre chose à faire ou ces valeurs ne sont pas assez strictes ? ou bien est ce pour un MBP et pas pour un MBA ?
j'avais les mêmes valeurs que Bartolomero après un -gcustom.
M
Membre supprimé 1060554
Invité
Bonjour Bunker
La commande que j'avais proposée à Bartolomeo vaut pour tout portable en situation d'alimentation sur batterie.
Passe quand même la commande :
Poste les tableaux en copier-coller > le coller dans une fenêtre de code ainsi -->
La commande que j'avais proposée à Bartolomeo vaut pour tout portable en situation d'alimentation sur batterie.
Passe quand même la commande :
Bloc de code:
pmset -g custom- qui affiche les 2 tableaux de paramètres de l'alimentation sur batterie et sur secteur
Poste les tableaux en copier-coller > le coller dans une fenêtre de code ainsi -->
- dans la page de ce fil de MacGé > presse le bouton
ici :
menu : </> Code > par ⌘V colle dans la fenêtre Code > presse le bouton Insérer (ce procédé permet un affichage fenêtré qui économise l'espace de page en respectant la mise en forme des tableaux du «Terminal» --> d'où une plus grande lisibilité)
Bloc de code:
Battery Power:
lidwake 1
autopoweroff 0
standbydelayhigh 900
autopoweroffdelay 28800
standbydelaylow 900
standby 1
ttyskeepawake 1
highstandbythreshold 50
powernap 0
gpuswitch 2
hibernatefile /var/vm/sleepimage
hibernatemode 3
displaysleep 5
sleep 10
acwake 0
halfdim 1
lessbright 1
disksleep 5j'ai juste mis le Battery car c'est uniquement ce point que je souhaiterais optimiser...enfin detour à la normale plutôt.
Dernière édition:
M
Membre supprimé 1060554
Invité
Tu as étendu à 900 secondes = 15' le délai de sommeil du kernel avant virage à l'hibernation : c'est trop long pour ce qui est de la problématique de ce fil.
Teste telle quelle la commande assez stricte que j'avais proposée :
Teste telle quelle la commande assez stricte que j'avais proposée :
Bloc de code:
sudo pmset -b autopoweroff 0 standby 1 standbydelayhigh 300 standbydelaylow 300 displaysleep 2 disksleep 2 sleep 3
