J'avais mis à jour mon ancien iMac vers Mavericks très bien. J'ai ensuite acheté un nouvel iMac (certifié remis à neuf, en fait) et j'ai tout migré à partir d'une sauvegarde Time Machine.

L'horloge du nouvel iMac perd plusieurs secondes par jour. Lorsque je déverrouille la préférence système Date et heure , l'heure se synchronise ensuite à l'heure correcte immédiatement. Mais cela perd encore du temps.

J'ai lu cette réponse et j'ai maintenant un total de 3 serveurs de temps, mais cela ne semble pas résoudre mon problème.

Dans le system.logfichier, il y a ces messages pertinents:

Dec  3 22:31:34 iMac.local ntpd[66350]: SYNC state ignoring +0.155735 s
Dec  3 22:31:35 iMac.local ntpd[66350]: ntpd: time set +0.308737 s
Dec  3 22:31:35 iMac.local com.apple.time[158]: Interval maximum value is 946100000 seconds (specified value: 9223372036854775807).

L' Interval maximum valueun n'a pas l'air bien.

Quelqu'un sait comment résoudre ce problème afin que l'heure reste synchronisée?

Mise à jour

Cela a pris un peu de temps, mais l'ajout de plusieurs serveurs de temps l' a rendu meilleur (pas parfait, mais meilleur). Maintenant, il gagne du temps, mais apparemment à un rythme beaucoup plus lent.

Si l'ajout de plusieurs serveurs (3 au total) avait quelque chose à voir avec l'amélioration, peut-être (?) L'ajout d'encore plus de serveurs le rendra encore meilleur. J'ai maintenant un total de 5 serveurs ntp.conf. Je vais le regarder au cours des prochains jours et voir ce qui se passe. (Même si cela le corrige, cela ne répond toujours pas pourquoi tout cela est nécessaire pour le corriger en premier lieu. Une réponse à cela serait bien, mais je me contenterai que cela soit corrigé à ce stade.)

BTW: vous pouvez en définir plusieurs via l' interface graphique des préférences système : il suffit de taper les noms de serveur dans le champ avec des virgules pour les séparer. Cela maintient l'interface graphique et le fichier synchronisés.

BTW # 2: voici le site d'où j'ai obtenu la liste des serveurs NTP accessibles au public.

Eh bien, certaines de ces questions (votre liste de puces, y compris "pourquoi 5 serveurs") sont un peu difficiles à répondre, la synchronisation de l'heure est tout à fait le trou du lapin. La vieille parabole de l'homme à une horloge sachant quelle heure il est mais l'homme à deux ne sachant jamais ...

Un serveur est un "truechimer" évident, toujours parce qu'il n'y a rien pour l'invalider. Deux serveurs est la "pire configuration possible" selon les auteurs du NTP car il ne saura jamais lequel est "plus" correct. Une fois que vous avez atteint trois serveurs, NTP peut commencer à marquer les horloges comme des «faussetickers» sur la base de certaines mesures internes - celles-ci apparaîtront avec un état «x» lorsque vous exécuterez ntpq -psur le système. Plus d'informations sur les colonnes et les indicateurs d'état de cette commande sont disponibles sur ntp.org .

Pour revenir au problème en cours, quelques notes:

• placer la ligne pool us.pool.ntp.org iburstdans votre /etc/ntp.conffichier ajoutera automatiquement quatre serveurs ntp stratum 2 du pool ntp à votre liste de serveurs de temps. Ceux-ci utilisent la rotation à tour de rôle DNS pour répartir la charge. Si vous n'êtes pas aux États-Unis, vous pouvez utiliser d'autres pools.

• vous ne pouvez pas faire la ligne de configuration du pool à partir de l'interface graphique des préférences système; vous pouvez toutefois mettre ce qui suit dans ce qui aurait le même effet: 0.us.pool.ntp.org, 1.us.pool.ntp.org, 2.us.pool.ntp.org, 3.us.pool.ntp.org.

• en sélectionnant vous-même les serveurs de temps, vous devez toujours vous assurer de sélectionner des serveurs "stratum 2" ou supérieurs (la meilleure pratique en ligne est de n'aller aux serveurs de la strate 1 que si vous fournissez du temps à des dizaines de machines localement). vous voudrez également vérifier les politiques dans la liste des serveurs de temps public avant de modifier le minpoll / maxpoll par défaut avec les serveurs publics, certains administrateurs ne veulent pas que vous modifiiez les valeurs par défaut (cela peut placer une charge plus élevée sur leurs serveurs publics). La meilleure approche consiste à simplement utiliser les serveurs de pool NTP.

• Je constate également un changement substantiel dans la qualité du temps depuis la mise à niveau vers Mavericks. Je viens d'ajouter plus de serveurs que vous l'avez fait pour voir si cela résout le problème, mais quelque chose a définitivement changé. J'ai un serveur de couche 1 sur mon réseau local et l'horloge de mon iMac dérive partout alors qu'avant la mise à niveau des Mavericks, ce n'était pas le cas.

Eh bien, avoir 5 serveurs NTP semble l'avoir résolu, donc je suppose que cette réponse était en fait la réponse pour le corriger , mais c'est une réponse insatisfaisante car elle ne répond pas aux questions suivantes:

• Pourquoi 5 serveurs?
• Pourquoi en a-t-on tant besoin?
• Pourquoi en faut-il plus d'une?
• Y a-t-il réellement un problème matériel avec la puce d'horloge qui la fait tellement dériver nécessitant donc 5 serveurs pour la garder correcte?

Je pense que Mavericks a fait la même chose avec mon Mac mini. Après quelques appels infructueux au support Apple (qui m'ont donné les solutions boiteuses standard comme la réinitialisation du p-ram), j'ai décidé de creuser moi-même.

J'ai observé que le démon ntp (ntpd) quitte / quitte après la première exécution après le démarrage du système. (trouvé en regardant les journaux système via l'utilitaire de la console et en filtrant par "ntp").

J'ai donné au support Apple un troisième appel pour trouver une solution plus appropriée que la modification des fichiers de configuration. J'ai parlé à l'un de leur personnel de support technique senior. Il m'a fait faire une autre réinitialisation de p-ram, mais aussi déplacer le dossier SystemConfiguration (situé dans le dossier Macintosh HD / Library / Preferences) dans la corbeille, vider la corbeille et redémarrer. Après quoi, j'ai dû configurer à nouveau mon WiFi et mon nom d'ordinateur (et plus tard mes préférences de partage d'écran, car j'utilise VNC pour le partage d'écran à distance).

Jusqu'à présent (environ 23 heures plus tard), je peux voir que ntpd continue de fonctionner:

12/6/13 10:14:13.648 AM ntpd[125]: ntpd: time set +0.963208 s
12/6/13 10:17:41.244 AM ntpd[125]: FREQ state ignoring +0.048040 s
12/6/13 10:18:51.412 AM ntpd[125]: FREQ state ignoring +0.065328 s
12/6/13 10:20:25.493 AM ntpd[125]: FREQ state ignoring +0.086068 s
12/6/13 10:23:01.588 AM ntpd[125]: FREQ state ignoring +0.121602 s
12/6/13 10:26:33.638 AM ntpd[125]: FREQ state ignoring +0.171160 s
12/6/13 10:31:06.911 AM ntpd[125]: ntpd: time set +0.233468 s
12/6/13 10:53:45.415 AM ntpd[125]: ntpd: time set +0.314875 s
12/6/13 11:58:56.335 AM ntpd[125]: SYNC state ignoring -0.375950 s
12/6/13 12:30:12.744 PM ntpd[125]: ntpd: time set -0.825345 s
12/6/13 1:47:54.647 PM ntpd[125]: SYNC state ignoring -1.119880 s
12/6/13 2:09:34.354 PM ntpd[125]: ntpd: time set -1.432706 s
12/6/13 3:49:25.547 PM ntpd[125]: SYNC state ignoring -1.439366 s
12/6/13 4:16:33.217 PM ntpd[125]: ntpd: time set -1.830211 s
12/6/13 10:33:28.790 PM ntpd[125]: SYNC state ignoring -0.411060 s
12/6/13 11:06:32.793 PM ntpd[125]: ntpd: time set -0.905610 s

Ce fil de discussion ressemblait à une bonne explication du problème et des solutions possibles.

https://discussions.apple.com/thread/5604114?start=45&tstart=0#27183298

Fondamentalement, le stimulateur cardiaque est en conflit avec le ntp modifié par Apple sur Mavericks. Plusieurs solutions proposées avec au moins: * compiler votre propre version de ntp ou restaurer à partir de pré-non-conformistes * forcer le toucher du fichier de dérive afin que le stimulateur cardiaque le relise

Je n'en ai pas encore essayé.

Il est cassé, même dans Mavericks 10.9.2. Les solutions que j'ai vues recommandées ne résolvent apparemment pas vraiment le problème. Il semble que le seul vrai correctif soit de remplacer le ntpd et la configuration cassés d'Apple. Pour une explication approfondie, voir le message de ce type: http://www.atmyoughtts.com/living-in-a-tech-family-blog/2014/2/28/what-time-is-it