<<que se passe t'il si mes machines locales doivent attendre 55 minutes avant que cron relance la tache? et bien on va pas être à l'heure pendant 55 minutes
Pas exactement: si le décalage n'est pas énorme, ntp va 'rattraper' le coup.>>
Oui mais justement, mon célèbre scénario du pire cas fait que c'est une grande différence ;-)
<<Sinon NTP peut fonctionner en broadcast il me semble. Ce ne sont plus les stations qui demandent l'heure mais ton serveur qui diffuse>>
Ca serait bien une solution oui, je comptais m'y attaquer dès lundi au broadcast, multicast, et manycast que propose NTP
<<je pense que ce qu'on me demande n'est tout simplement soit pas faisable, soit pas indiqué avec le protocole NTP.
C'est aussi ce que je pense. Voir http://www.hsc.fr/ressources/breves/ntp-auth.html.fr pour une description du fonctionnement de NTP. Il est bien dit que NTP est conçu pour ne jamais revenir en arrière et utilise les appels systèmes permettant d'"accélérer" ou de "ralentir" le décompte du temps.>>
Moi j'ai bien lu l'article que tu dis plusieurs fois, et ce n'est pas le seul qui dit que NTP est conçu pour ne jamais revenir en arrière mais ça n'est pas vrai pour moi. En effet, NTP quand il y a une trop grande différence entre l'horloge de référence et l'horloge du serveur (> 1000 secondes par défaut) fait ce qu'il apelle un STEP ADJUSTEMENT, c'est à dire qu'il met à l'heure l'horloge d'un seul coup, pas en ralentissant ou en augmentant le décompte du temps... il est donc parfaitement possible de revenir en arrière dans ce cas là!
<<.. mais on me demande pas à tout prix de le faire, on me demande si c'est envisageable et surtout utile mais moi, je pense dire non dans le pire des cas.
Ben le fait d'être utile ou non dépend de ce qui va derrière. Ca dépend aussi du matériel présent sur le réseau. Faut voir aussi la dérive de l'horloge de ta carte qui te sert de base de temps .>>
C'est exactement ce que j'ai répondu dans un doc interne tout à l'heure décrivant mon avancement, c'est que dans ce scénario du pire cas, il contient à l'utilisateur de la carte (je rapelle qu'à terme, le serveur NTP se trouvera sur une carte embarquée) de garantir que son horloge est correct sinon, cela revient à foutre le modèle NTP en vrac. J'ai pris cette exemple, en gros, NTP est organisé en strate, chaque strate synchronisant la couche qui est en dessous et se synchronisant avec la couche qui est au dessus... et bien dans mon cas, ça revient à intercaler une strate foireuse au milieu ce qui, on le comprends naturellement est un peu abérrant!
Bon en tout cas merci pour tes réponses, là, c'est le week end, mais promis, dès lundi je donne des nouvelles de mon avancement, et notamment l'utilisation des options de broadcast et de multicast, vu que ça à l'air de t'interesser et je me dis surtout que si qq'un à le même problème par la suite, sera bien content de trouver ces quelques éléments!
[^] # Re: Et un module qui fournit l'heure par RS232 par exemple?
Posté par the_ionic . En réponse au message Je reviens avec mon NTP. Évalué à 0.
Pas exactement: si le décalage n'est pas énorme, ntp va 'rattraper' le coup.>>
Oui mais justement, mon célèbre scénario du pire cas fait que c'est une grande différence ;-)
<<Sinon NTP peut fonctionner en broadcast il me semble. Ce ne sont plus les stations qui demandent l'heure mais ton serveur qui diffuse>>
Ca serait bien une solution oui, je comptais m'y attaquer dès lundi au broadcast, multicast, et manycast que propose NTP
<<je pense que ce qu'on me demande n'est tout simplement soit pas faisable, soit pas indiqué avec le protocole NTP.
C'est aussi ce que je pense. Voir http://www.hsc.fr/ressources/breves/ntp-auth.html.fr pour une description du fonctionnement de NTP. Il est bien dit que NTP est conçu pour ne jamais revenir en arrière et utilise les appels systèmes permettant d'"accélérer" ou de "ralentir" le décompte du temps.>>
Moi j'ai bien lu l'article que tu dis plusieurs fois, et ce n'est pas le seul qui dit que NTP est conçu pour ne jamais revenir en arrière mais ça n'est pas vrai pour moi. En effet, NTP quand il y a une trop grande différence entre l'horloge de référence et l'horloge du serveur (> 1000 secondes par défaut) fait ce qu'il apelle un STEP ADJUSTEMENT, c'est à dire qu'il met à l'heure l'horloge d'un seul coup, pas en ralentissant ou en augmentant le décompte du temps... il est donc parfaitement possible de revenir en arrière dans ce cas là!
<<.. mais on me demande pas à tout prix de le faire, on me demande si c'est envisageable et surtout utile mais moi, je pense dire non dans le pire des cas.
Ben le fait d'être utile ou non dépend de ce qui va derrière. Ca dépend aussi du matériel présent sur le réseau. Faut voir aussi la dérive de l'horloge de ta carte qui te sert de base de temps .>>
C'est exactement ce que j'ai répondu dans un doc interne tout à l'heure décrivant mon avancement, c'est que dans ce scénario du pire cas, il contient à l'utilisateur de la carte (je rapelle qu'à terme, le serveur NTP se trouvera sur une carte embarquée) de garantir que son horloge est correct sinon, cela revient à foutre le modèle NTP en vrac. J'ai pris cette exemple, en gros, NTP est organisé en strate, chaque strate synchronisant la couche qui est en dessous et se synchronisant avec la couche qui est au dessus... et bien dans mon cas, ça revient à intercaler une strate foireuse au milieu ce qui, on le comprends naturellement est un peu abérrant!
Bon en tout cas merci pour tes réponses, là, c'est le week end, mais promis, dès lundi je donne des nouvelles de mon avancement, et notamment l'utilisation des options de broadcast et de multicast, vu que ça à l'air de t'interesser et je me dis surtout que si qq'un à le même problème par la suite, sera bien content de trouver ces quelques éléments!