Depuis le changement d'heure, je n'arrive plus =E0 poster dans les news.
Pour poster ce message, j'ai d=FB retarder mon PC d'1 heure.
Sinon, j'ai ce message :
A News (NNTP) error occurred: Wrong client's clock
Le serveur de news que j'utilise : news.aioe.org
Et je lis les news dans mozilla.
Et je n'ai pas de probl=E8me depuis le boulot (win XP).
Ca semble venir de ma config...
Savez vous comment r=E9gler ce probl=E8me ?
Dans le message <news:dlv25q$7nl$, ** tapota sur f.c.o.l.configuration :
Sur Windows XP et 2003 le service tourne par défaut et se synchronise régulièrement sur le serveur de temps de Microsoft.
Mine de rien il en connaît un rayon sur Windows ;-)
Hehe, peut être plus que sur Linux en fait. Mais, contrairement à Linux, mes contributions à Windows sont très rares. Par exemple tu me verras très rarement poster sur fr.comp.os.ms-windows.* alors que je te vois y contribuer de temps en temps. :)
[Plaidoyer pour ntpd]
:-)
J'utilise le serveur NTP de mon FAI que je paie, alors j'espère bien qu'il ne limite pas mes requêtes.
Certes, mais n'est-on jamais mieux servis que par sois-même ? :-P Sinon, je note que metroid (me tape pas encore Raphit) dérive un peu plus que ses collègues. :-)
La deuxième raison, c'est que sur un réseau où des machines partagent entre-elles différentes ressources, il est important que celles-ci aient la même référence de temps.
Certes, mais là on ne parle pas d'un vrai réseau d'entreprise sérieux mais de mon petit réseau domestique de quatre machines qui ne partagent rien
Et moi qui t'imaginais avec un super réseau. Je suis déçu. :-
c'est une des fonctions de ntpd [...] que de corriger ces dérives d'horloge qui sont fréquentes sur nos PC.
Il me semblait qu'il existait un autre moyen de corriger la dérive d'horloge, sans avoir besoin de faire tourner un démon en permanence.
Oui, il est possible, grâce au contenu du fichier /etc/adjtime et à la commande 'hwclock', de corriger la dérive de l'horloge système. Seulement ça nécessite une intervention humaine. De plus, mes observations m'ont montré que la dérive moyenne peut varier avec le temps.
Avec ntpd la dérive est calculée automatiquement et en permanence.
Enfin, le protocole NTP est une bonne introduction sur la mise en pratique du protocole broadcast et surtout du protocole multicast, mais aussi sur la sécurisation des données échangées avec le protocole UDP connu pour être facilement «spoofé».
Ahem... multicast, crypto... justement les sujets qui fâchent. :(
Vraiment ? Pour la crypto je peux comprendre, il faut d'abord assimiler pas mal de chose pour pouvoir mettre ça en pratique de manière confortable. Pour le multicast, ça me semblait tomber pil poil dans ton domaine.
Conclusion, cela te semble-t-il convaincant ? La curiosité qu'on te connait, va-t-elle se laisser tenter par l'expérience NTP ? :-P
J'ai peur que la curiosité ne soit pas suffisante au regard du rapport bénéfice/investissement que ça demanderait. C'est un métier tout ça, et ce n'est pas le mien.
Oh, là aussi je suis déçu ; je pensais sincèrement que je t'aurai convaincu. :-)
-- TiChou
Dans le message <news:dlv25q$7nl$1@biggoron.nerim.net>,
*Pascal@plouf* tapota sur f.c.o.l.configuration :
Sur Windows XP et 2003 le service tourne par défaut et se synchronise
régulièrement sur le serveur de temps de Microsoft.
Mine de rien il en connaît un rayon sur Windows ;-)
Hehe, peut être plus que sur Linux en fait. Mais, contrairement à Linux, mes
contributions à Windows sont très rares.
Par exemple tu me verras très rarement poster sur fr.comp.os.ms-windows.*
alors que je te vois y contribuer de temps en temps. :)
[Plaidoyer pour ntpd]
:-)
J'utilise le serveur NTP de mon FAI que je paie, alors j'espère bien qu'il
ne limite pas mes requêtes.
Certes, mais n'est-on jamais mieux servis que par sois-même ? :-P
Sinon, je note que metroid (me tape pas encore Raphit) dérive un peu plus
que ses collègues. :-)
La deuxième raison, c'est que sur un réseau où des machines partagent
entre-elles différentes ressources, il est important que celles-ci aient
la même référence de temps.
Certes, mais là on ne parle pas d'un vrai réseau d'entreprise sérieux mais
de mon petit réseau domestique de quatre machines qui ne partagent rien
Et moi qui t'imaginais avec un super réseau. Je suis déçu. :-
c'est une des fonctions de ntpd [...] que de corriger ces dérives
d'horloge qui sont fréquentes sur nos PC.
Il me semblait qu'il existait un autre moyen de corriger la dérive
d'horloge, sans avoir besoin de faire tourner un démon en permanence.
Oui, il est possible, grâce au contenu du fichier /etc/adjtime et à la
commande 'hwclock', de corriger la dérive de l'horloge système. Seulement ça
nécessite une intervention humaine. De plus, mes observations m'ont montré
que la dérive moyenne peut varier avec le temps.
Avec ntpd la dérive est calculée automatiquement et en permanence.
Enfin, le protocole NTP est une bonne introduction sur la mise en
pratique du protocole broadcast et surtout du protocole multicast, mais
aussi sur la sécurisation des données échangées avec le protocole UDP
connu pour être facilement «spoofé».
Ahem... multicast, crypto... justement les sujets qui fâchent. :(
Vraiment ? Pour la crypto je peux comprendre, il faut d'abord assimiler pas
mal de chose pour pouvoir mettre ça en pratique de manière confortable.
Pour le multicast, ça me semblait tomber pil poil dans ton domaine.
Conclusion, cela te semble-t-il convaincant ? La curiosité qu'on te
connait, va-t-elle se laisser tenter par l'expérience NTP ? :-P
J'ai peur que la curiosité ne soit pas suffisante au regard du rapport
bénéfice/investissement que ça demanderait. C'est un métier tout ça, et ce
n'est pas le mien.
Oh, là aussi je suis déçu ; je pensais sincèrement que je t'aurai
convaincu. :-)
Dans le message <news:dlv25q$7nl$, ** tapota sur f.c.o.l.configuration :
Sur Windows XP et 2003 le service tourne par défaut et se synchronise régulièrement sur le serveur de temps de Microsoft.
Mine de rien il en connaît un rayon sur Windows ;-)
Hehe, peut être plus que sur Linux en fait. Mais, contrairement à Linux, mes contributions à Windows sont très rares. Par exemple tu me verras très rarement poster sur fr.comp.os.ms-windows.* alors que je te vois y contribuer de temps en temps. :)
[Plaidoyer pour ntpd]
:-)
J'utilise le serveur NTP de mon FAI que je paie, alors j'espère bien qu'il ne limite pas mes requêtes.
Certes, mais n'est-on jamais mieux servis que par sois-même ? :-P Sinon, je note que metroid (me tape pas encore Raphit) dérive un peu plus que ses collègues. :-)
La deuxième raison, c'est que sur un réseau où des machines partagent entre-elles différentes ressources, il est important que celles-ci aient la même référence de temps.
Certes, mais là on ne parle pas d'un vrai réseau d'entreprise sérieux mais de mon petit réseau domestique de quatre machines qui ne partagent rien
Et moi qui t'imaginais avec un super réseau. Je suis déçu. :-
c'est une des fonctions de ntpd [...] que de corriger ces dérives d'horloge qui sont fréquentes sur nos PC.
Il me semblait qu'il existait un autre moyen de corriger la dérive d'horloge, sans avoir besoin de faire tourner un démon en permanence.
Oui, il est possible, grâce au contenu du fichier /etc/adjtime et à la commande 'hwclock', de corriger la dérive de l'horloge système. Seulement ça nécessite une intervention humaine. De plus, mes observations m'ont montré que la dérive moyenne peut varier avec le temps.
Avec ntpd la dérive est calculée automatiquement et en permanence.
Enfin, le protocole NTP est une bonne introduction sur la mise en pratique du protocole broadcast et surtout du protocole multicast, mais aussi sur la sécurisation des données échangées avec le protocole UDP connu pour être facilement «spoofé».
Ahem... multicast, crypto... justement les sujets qui fâchent. :(
Vraiment ? Pour la crypto je peux comprendre, il faut d'abord assimiler pas mal de chose pour pouvoir mettre ça en pratique de manière confortable. Pour le multicast, ça me semblait tomber pil poil dans ton domaine.
Conclusion, cela te semble-t-il convaincant ? La curiosité qu'on te connait, va-t-elle se laisser tenter par l'expérience NTP ? :-P
J'ai peur que la curiosité ne soit pas suffisante au regard du rapport bénéfice/investissement que ça demanderait. C'est un métier tout ça, et ce n'est pas le mien.
Oh, là aussi je suis déçu ; je pensais sincèrement que je t'aurai convaincu. :-)
-- TiChou
TiChou
Dans le message <news:dlv3mh$85b$, *Nicolas George* tapota sur f.c.o.l.configuration :
Enfin, le protocole NTP est une bonne introduction sur la mise en pratique du protocole broadcast et surtout du protocole multicast
Au fait, il faut quand même rappeler que le NTP passif en (broad|multi)cast est moins précis que le NTP actif par interrogation du serveur (parce que dans ce dernier cas, le client connaît le round-trip).
En broadcast oui. Mais en multicast cela dépend du client. Par exemple, les clients ntp version 4, après avoir reçu un paquet multicast, vont dialoguer en unicast avec le serveur.
-- TiChou
Dans le message <news:dlv3mh$85b$1@biggoron.nerim.net>,
*Nicolas George* tapota sur f.c.o.l.configuration :
Enfin, le protocole NTP est une bonne introduction sur la mise en
pratique du protocole broadcast et surtout du protocole multicast
Au fait, il faut quand même rappeler que le NTP passif en
(broad|multi)cast est moins précis que le NTP actif par interrogation du
serveur (parce que dans ce dernier cas, le client connaît le round-trip).
En broadcast oui. Mais en multicast cela dépend du client. Par exemple, les
clients ntp version 4, après avoir reçu un paquet multicast, vont dialoguer
en unicast avec le serveur.
Dans le message <news:dlv3mh$85b$, *Nicolas George* tapota sur f.c.o.l.configuration :
Enfin, le protocole NTP est une bonne introduction sur la mise en pratique du protocole broadcast et surtout du protocole multicast
Au fait, il faut quand même rappeler que le NTP passif en (broad|multi)cast est moins précis que le NTP actif par interrogation du serveur (parce que dans ce dernier cas, le client connaît le round-trip).
En broadcast oui. Mais en multicast cela dépend du client. Par exemple, les clients ntp version 4, après avoir reçu un paquet multicast, vont dialoguer en unicast avec le serveur.
-- TiChou
dyrmak
Sébastien Kirche wrote:
Le 21 novembre 2005 à 09:11, dyrmak a dit :
En 15 lignes moi a écrit dans news:dlqf7b$ksa$ le dimanche, 20 novembre 2005 à 19:21:56 :
Bonjour,
Je ne comprend pas trop là, tu dis bonjour
mais c'est plutôt le soir ?
C'est parce que Usenet est asynchrone :p
Train en retard, correspondance ratée, embouteillage chronique et dans Venus le jour est plus long que l'année... ... Bon ça c'est pas moi qui le dis ;)
dyrmak
Sébastien Kirche wrote:
Le 21 novembre 2005 à 09:11, dyrmak a dit :
En 15 lignes moi a écrit
dans news:dlqf7b$ksa$1@domitilla.aioe.org
le dimanche, 20 novembre 2005 à 19:21:56 :
Bonjour,
Je ne comprend pas trop là, tu dis bonjour
mais c'est plutôt le soir ?
C'est parce que Usenet est asynchrone :p
Train en retard, correspondance ratée, embouteillage chronique
et dans Venus le jour est plus long que l'année...
... Bon ça c'est pas moi qui le dis ;)
En 15 lignes moi a écrit dans news:dlqf7b$ksa$ le dimanche, 20 novembre 2005 à 19:21:56 :
Bonjour,
Je ne comprend pas trop là, tu dis bonjour
mais c'est plutôt le soir ?
C'est parce que Usenet est asynchrone :p
Train en retard, correspondance ratée, embouteillage chronique et dans Venus le jour est plus long que l'année... ... Bon ça c'est pas moi qui le dis ;)
