Ce n'est pas tant la rapidité du réseau qui compte que sa régularité, puisque NTP corrige l'heure envoyée par le serveur en utilisant le temps de trajet (temps de réponse divisé par deux). Si la requête a mis 10 ms à parvenir au serveur mais que sa réponse en à mis 100 à revenir, la correction va être fausse!
Tu as raison. Il y a la symétrie qui joue : certains types de connexions réseau peuvent être tout à fait réguliers et fortement asymétriques. Il n'y a aucun moyen de le déterminer sans avoir une autre connexion réseau pour calibrer. Je soupçonne que l'ADSL est un peu dans ce cas.
Jérémy JUST wrote in message
<20040829143243.4e066caf@norbert.inapg.inra.fr>:
Ce n'est pas tant la rapidité du réseau qui compte que sa régularité,
puisque NTP corrige l'heure envoyée par le serveur en utilisant le temps
de trajet (temps de réponse divisé par deux).
Si la requête a mis 10 ms à parvenir au serveur mais que sa réponse en
à mis 100 à revenir, la correction va être fausse!
Tu as raison. Il y a la symétrie qui joue : certains types de connexions
réseau peuvent être tout à fait réguliers et fortement asymétriques. Il n'y
a aucun moyen de le déterminer sans avoir une autre connexion réseau pour
calibrer. Je soupçonne que l'ADSL est un peu dans ce cas.
Ce n'est pas tant la rapidité du réseau qui compte que sa régularité, puisque NTP corrige l'heure envoyée par le serveur en utilisant le temps de trajet (temps de réponse divisé par deux). Si la requête a mis 10 ms à parvenir au serveur mais que sa réponse en à mis 100 à revenir, la correction va être fausse!
Tu as raison. Il y a la symétrie qui joue : certains types de connexions réseau peuvent être tout à fait réguliers et fortement asymétriques. Il n'y a aucun moyen de le déterminer sans avoir une autre connexion réseau pour calibrer. Je soupçonne que l'ADSL est un peu dans ce cas.
no_spam
On Sun, 29 Aug 2004 12:36:19 +0000, Nicolas George wrote:
no_spam wrote in message :
Donc, l'horloge ne sera pas à l'heure à la nano-seconde prêt, mais sera maintenue avec une précision de cet ordre.
Ça aussi, c'est faux : le contrôleur d'interruptions d'un PC, typiquement, est loin d'être aussi précis. Enfin, ce que tu dis n'a en soi pas grand sens : il faudrait parler d'erreur relative.
Le timer système est effectivement bcp moins précis que la nano-seconde, mais tous les CPU récents (depuis le Pentium (?) en x86) intègrent un compteur de cycle qui permet de corriger la dérive. Au démarage, Linux effectue un calibrage des timers (c'est le fameux calcul des bogomips) en utilisant la RTC, le timer système et le compteur de cycle. Il prend aussi en compte, s'il l'info existe, les paramêtres du BIOS lui donnant la fréquence exacte du CPU (ça ne marche qu'en ACPI, je crois). Sur un CPU qui n'a pas de compteur de cycles, la dérive peut effectivement devenir plus importante puisqu'il n'y a pas de référence de temps très précise. Et dans le cas des CPU dont la fréquence peut varier, le problème est un peu plus complexe, mais comme ce sont tous des CPU récents, ça ne pose pas de problème fondamental.
On Sun, 29 Aug 2004 12:36:19 +0000, Nicolas George wrote:
no_spam wrote in message <pan.2004.08.29.12.11.36.341623@magic.fr>:
Donc, l'horloge ne sera pas à l'heure à la nano-seconde prêt, mais
sera maintenue avec une précision de cet ordre.
Ça aussi, c'est faux : le contrôleur d'interruptions d'un PC, typiquement,
est loin d'être aussi précis. Enfin, ce que tu dis n'a en soi pas grand
sens : il faudrait parler d'erreur relative.
Le timer système est effectivement bcp moins précis que la nano-seconde,
mais tous les CPU récents (depuis le Pentium (?) en x86) intègrent un
compteur de cycle qui permet de corriger la dérive.
Au démarage, Linux effectue un calibrage des timers (c'est le fameux
calcul des bogomips) en utilisant la RTC, le timer système et le compteur
de cycle. Il prend aussi en compte, s'il l'info existe, les paramêtres
du BIOS lui donnant la fréquence exacte du CPU (ça ne marche qu'en ACPI,
je crois).
Sur un CPU qui n'a pas de compteur de cycles, la dérive peut
effectivement devenir plus importante puisqu'il n'y a pas de référence
de temps très précise.
Et dans le cas des CPU dont la fréquence peut varier, le problème est un
peu plus complexe, mais comme ce sont tous des CPU récents, ça ne pose
pas de problème fondamental.
On Sun, 29 Aug 2004 12:36:19 +0000, Nicolas George wrote:
no_spam wrote in message :
Donc, l'horloge ne sera pas à l'heure à la nano-seconde prêt, mais sera maintenue avec une précision de cet ordre.
Ça aussi, c'est faux : le contrôleur d'interruptions d'un PC, typiquement, est loin d'être aussi précis. Enfin, ce que tu dis n'a en soi pas grand sens : il faudrait parler d'erreur relative.
Le timer système est effectivement bcp moins précis que la nano-seconde, mais tous les CPU récents (depuis le Pentium (?) en x86) intègrent un compteur de cycle qui permet de corriger la dérive. Au démarage, Linux effectue un calibrage des timers (c'est le fameux calcul des bogomips) en utilisant la RTC, le timer système et le compteur de cycle. Il prend aussi en compte, s'il l'info existe, les paramêtres du BIOS lui donnant la fréquence exacte du CPU (ça ne marche qu'en ACPI, je crois). Sur un CPU qui n'a pas de compteur de cycles, la dérive peut effectivement devenir plus importante puisqu'il n'y a pas de référence de temps très précise. Et dans le cas des CPU dont la fréquence peut varier, le problème est un peu plus complexe, mais comme ce sont tous des CPU récents, ça ne pose pas de problème fondamental.
