salut à tous
> il y a environ 20 ans j'ai appris que le reseau EDF fournissait un signal
> 50 hz tres precis au point que de nombreuses horloges utilisent ce signal
> pour leur precision
> qu'en est il aujourd'hui ?
> est ce que c'est toujours le cas ? , partout ?
>
> une autre question :
> j'ai noté que pas mal de cartes meres d'ordinateur dervent beaucoup
> à quoi cela est il du à l'epoque des quartzs ?
============ Le 50 Hz n'est pas un étalon de fréquence, il varie en fonction de critères techniques (consommation production) toutefois la tolérance est étroite Quand aux ordinateurs, l'oscillateur n'est pas thermostaté mais la précision est suffisante pour un usage "ménager" Toutefois, lorsqu'on est connecté "web" , le recalage se fait automatiquement
Les unix et windows règlent tous leur horloge depuis les serveurs (sauf si tu désactives le service ou que l'ordi n'est pas conencté au net bien sur c'est pas magique...) mais par défaut c'est activé, ça fait un bail que c'est comme ça c'est pas nouveau :)
Le Wed, 02 Dec 2009 14:36:27 +0100, LeLapin a écrit :
Je te prie de m'excuser : je demande sur quel serveur NTP Windows se synchronise d'office, pas un serveur NTP.
Je le reprends le fil : Le 50 Hz n'est pas un étalon de fréquence, il varie en fonction de critères techniques (consommation production) toutefois la tolérance est étroite Quand aux ordinateurs, l'oscillateur n'est pas thermostaté mais la précision est suffisante pour un usage "ménager" Toutefois, lorsqu'on est connecté "web" , le recalage se fait automatiquement
je demande sur quel serveur NTP Windows se synchronise d'office, pas un serveur NTP quelconque comm moi. Par exemple dans mon crontab
moi-meme a tapoté du bout de ses petites papattes :
Le serveur NTP par défaut de windows (je ne parle que pour XP, il y en a peut-être de nouveaux) est time.windows.com mais nist.gov est proposé en second choix.
XP se synchronise sur le NTP de Microsoft. Il est param=E9trable; le nom figure dans le pannel de configuration (le truc de gestion de l'horloge).
Le NTP n'est dispo que depuis 2k. Avant, MS ne connaissait pas le NTP.
Exemple typique de ce qu'il ne faut JAMAIS faire.
1: sous Linux, faut le demander
2: faire une synchro bruptale, c'est le meilleur moyen de p=E9ter sa conf.
3: c'est pas parce que Windows fait une synchro bruptale tous les dimanches, que c'est ce qu'il faut faire.
donc:
- ntpdate fait une synchro bruptale; c'est ce qu'il faut au boot, pour rectifier l'erreur accumul=E9e par une machine =E9teinte. Il faut le faire EXCLUSIVEMENT au boot. Si une synchro bruptale survient dans un system en fonctionnement ... si on avance de beaucoup (disons 3 s), =E7a peut faire tourner en bourique certains services, ou faire rater des =E9v=E8nements. Si par exemple cette synchro rajoute 3s, 1s avant une nouvelle heure ou un nouveau jour, =E7a peut faire rater l'=E9v=E8nement "heure pleine =E0 minute nulle" aux services qui se basent sur =E7a ... y compris cron lui m=EAme, m=EAme si tu fais g=E9rer =E7a par cron, pour des raisons qui me prendraient 5 pages =E0 expliquer. Si tu fais un saut en arri=E8re, m=EAme de 1s, tu te retrouve au contraire avec l'=E9ventualit=E9= de rencontrer "deux fois cons=E9cutives =E0 2s homme d'intervalle", =E0 renconrer le dit =E9v=E8nement; et le soft concern=E9 pourrait par exemple, lancer deux fois, =E0 une seconde d'intervalle, une tache cens=E9e n'=EAtre faite qu'une fois par heure, jour, mois ... et =E7a peut =EAtre CATASTROPHIQUE si le d=E9mon concern=E9 est proche d'un syst=E8me de fichier, server email, ou base de type SQL. Pire, si le FS se base pas sur une heure de m=EAme type que la base SQL, en fait, tu as la garantie que tu va faire exploser tes locks (genre, un sur la RTc, l'autre sur les ticks)
- ntpd est le d=E9mon =E0 lancer au boot, apr=E8s l'execution de ntpdate. ntpd maintient l'heure de la RTC, par deux types d'ajustements, selon la configuration hard et soft.
1: micro sauts: il ajoute ou retranche du temps =E0 la RTC, mais par quantit=E9s tellement infimes que =E7a ne peut pas perturber aucun d=E9mon install=E9
2: le coefficient du driver: il change le ratio qui compte le nombre de cycles de quartz pour faire une seconde. Ca permet de corriger, en temps r=E9el, la temp=E9rature: =E0 froid, il va voir que le temps passe d'une mani=E8re; et 2h plus tard, quand la CM a chaud, il va constater qu'il faut faire changer le nombre de ticks par seconde pour avoir une seconde "correcte".
Les d=E9mons ntpd ne se valent pas tous. Par exemple, chrony peut rattrapper 2mn de retard en 1h. open-ntp mettra 4j. Ca a des avantages, et des inconv=E9nients. Je conseille donc chrony pour une machine qui risque d'avoir des probl=E8mes de temps, et pour diverses raisons, pourrait ne pas avoir internet au boot, mais seulement apr=E8s le boot (donc, pas de ntpdate possible au boot; mais une connexion deviendrait dispo quelques minutes plus tard. Cas typique: un PC portable ou c'est l'usager qui va configurer =E0 la main, =E0 chaque cession, le r=E9seau wifi =E0 utiliser). open-ntp sera moins sensible aux erreurs =E0 court terme d'un server donn=E9.
Mais si tu as envie de risquer la perte de donn=E9es, ou le bug dans les services de tes machines ... libre =E0 toi. Tu as peut =EAtre lu sur des forums de mettre ntpdate dans crontab; mais AUCUNE distro ne fait =E7a automatiquement. Alors que si tu installe ntpdate et ntp, les deux ensemble, que ce soit sur Debian ou Gentoo, =E7a marche comme j'ai dit: ntpdate au boot, puis ENSUITE, ntpd.
Classe 82 ... tu sens l'abonn=E9 Free.
Alors, note au passage que leurs servers NTP d=E9lirent totalement. Ils ne sont pas toujours joignables, et donnent parfois une heure erronn=E9e. Mais, libre =E0 toi ... de refuser d'utiliser les NTP fournis par ... ta distro (quelle distro n'a pas son propre pool ntp ? peut =EAtre LFS :D ), dans le package de ntpdate, GNU et l'APRIL, pool.ntp.org, les gouvernements, des tonnes d'instituts priv=E9s et publiques offrant leur horloge atomique ...
Puis r=E9gler son horloge sur un server unique, c'est suicidaire, et contraire =E0 la RFC (qui pr=E9conise d'en utiliser au moins 3, et si possible 5 ou 7).
Vaut encore mieux ne rien faire du tout, que de mettre =E7a dans son cron.
Le Wed, 02 Dec 2009 16:29:22 -0800, Doublehp a écrit :
----------------->snip multiples Mais si tu as envie de risquer la perte de données, ou le bug dans les
oui c'est le serveur NTP le plus proche. Je lui faisais confiance.
manip un peu suicidaire comme tu m'as dit : morgane:/home/moi# ntpdate 0.fr.pool.ntp.org 3 Dec 13:13:56 ntpdate[5099]: step time server 88.191.33.101 offset
je vide la crontab et j'installe crony avec plusieurs serveurs (pour info je suis sous Debian, il indique les serveurs Debian d'office :
server 0.debian.pool.ntp.org offline minpoll 8 server 1.debian.pool.ntp.org offline minpoll 8 server 2.debian.pool.ntp.org offline minpoll 8 server 3.debian.pool.ntp.org offline minpoll 8
je garde pour voir.
merci pour les tuyaux.
PS : mauvais pseudo : pas Doublehp mais Doublehelp :-)
M=EAme le plus mauvais NTP aura une fiabilit=E9 de 99.999%. Tu n'avais qu'une chance sur un million d'avoir un probl=E8me en lancant =E7a =E0 la main. Surtout si, au moment de me lire, tu avais du net.
La probabilit=E9 de probl=E8me monte en fl=E8che quand le r=E9seau explose; par exemple, comme le 18 novembre dernier =E0 minuit quand le DSLAM est coup=E9 du coeur de free ... mais tu reste connect=E9 au DSLAM ... et l=E0, avec un peu de chance, tu te prends un magnifique saut temporel en pleine face.
T'a jamais vu la Freebox indiquer "la mauvaise heure" ? genre 1h00 =E0
5h de l'aprem, ou 3h42 en soir=E9e ... moi d=E9j=E0 deux fois en 5 ans.
Avec le temps, on peux pas tol=E9rer une fiabilit=E9 de 99.999%. On peux tol=E9rer un jit de plusieurs secondes, mais on ne peux jamais, JAMAIS tol=E9rer de saut bruptal dans le temps sur une machine active, ni en avant, ni en arri=E8re. Faudrait apriori jamais qu'une correction instantann=E9e ne d=E9passe pas la dur=E9e d'un cycle de scheduler. On ne peux pas non plus tol=E9rer d'avoir un NTP unique; m=EAme en locale il en faut au moins 3 (pour plein de raisons; dont la plus grave: si la propabilit=E9 qu'un server fasse une erreur durant une requette est de
1:10^6, alors, la probabilit=E9 que les 3 servers apportent la m=EAme mauvaise r=E9ponse d=E9passe de tr=E8s loin
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.