Re: ntp et daytime
On Wed, 24 Apr, 2002 à 06:33:05PM +0200, georges mariano wrote:
>
> un peu par hasard en explorant webmin (beau joujou ;-)
> je tombe sur ça :
> serveur de temps
> avec le commentaire suivant :
> <<Un serveur peut offrir le service 'daytime' qui renvoie l'heure
> courante du système.
> Ce service peut être offert à l'interne par inetd.
>
> Ce résultat peut être appliqué à l'heure système ou matériel.>>
>
>
> Question simple :
> quel lien comparatif peut-on établir avec ntp ??
> (fonctionnalité/fiabilité/sécurité ??)
Pas le même but, daytime permet de savoir l'heure de la machine distante,
ntp permet de synchronyser ton horloge avec l'horloge distante, pas
seulement avoir la même heure, mais aussi évoluer à la même vitesse.
ntp est plus complexe : la machine A veut demander l'heure à la machine
B.
daytime :
A : « Hé, B, quelle heure est-il ? »
B : « Il est 17h30m22s »
A met son horloge à l'heure que lui a donné B.
quelques pbs : la réponse de B n'est précise qu'à la seconde près, on ne
sait pas combien de temps la question à mise pour parvenir à B, combien
de temps B (qui est un peu dur de la feuille) a mis pour traiter la
question, ni combien de temps il a fallu à la réponse de B pour parvenir
à A.
ntp :
A : « Hé B, quelle heure est-il ?» et je note que j'ai posé la question
à l'instant M_0
B : « J'ai reçu ta question à 17h30m22,106307s et maintenant il est
17h30m22,835279s »
A reçoit la réponse de B en M_1, note combien de temps s'est écoulé
entre l'émission de la question et l'obtention de la réponse, soustrait
le temps que B a mis à répondre le résultat donnant T. T/2 est considéré
comme étant le temps de trajet de A vers B (les temps de parcours
nettement assymétriques demandent des précautions spéciales, je
simplifie donc). A sait maintenant que lorsque lui pensait qu'il était
M_0+T/2, B pensait qu'il était 17h30m22,106307s, il sait maintenant
qu'elle différence d présentaient leurs horloges respectives à l'instant
ou B a reçu la question. Si leurs horloges évoluaient à la même vitesse,
A pourrait se dire que lorsqu'il reçoit la réponse de B l'heure de B est
17h30m22,835279s+T/2 mais c'est hélas faux. Supposons que l'intervalle
séparant M_0 et M_1 fasse 2 secondes vu par B et 3 secondes vue par A
(c'est caricatural, c'est juste pour aider à voir où est le hiatus). La
seule info fiable obtenue par cet unique échange c'est la valeur du
couple (17h30m22,106307s ; d), il faut collecter plusieurs tels couples
pour connaitre les vitesses relatives des deux horloges (si d est
constant on va à la même vitesse, d augmente A va trop vite, d diminue A
est trop lent). Une fois l'écart et les vitesses relatives connus, on
peut commencer à corriger l'horloge de A.
Nettement plus complexe, non ?
Ceci dit, la précision est bien meilleure (micro, voire nano secondes),
l'info collectée est bien plus importante.
Resterait à expliquer les mécanismes de sélection d'un serveur quand on
interroge plusieurs, cela nous entrainerait un peu loin sachant que j'ai
bcp simplifié ce qui se passe pour un échange le client (A dans mon
exemple) fait plus de calcul que cela.
--
( >- Laurent PICOULEAU -< )
/~\ laurent@nerim.net /~\
| \) Linux : mettez un pingouin dans votre ordinateur ! (/ |
\_|_ Seuls ceux qui ne l'utilisent pas en disent du mal. _|_/
--
To UNSUBSCRIBE, email to debian-user-french-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: