c'est quoi encore ce pb :
Warning: session_start():
open(sessions/sess_f3b08046734a64fb76f54655a6bbc6b3, O_RDWR) failed: No
space left on device (28) in /home/www/accueil.php on line 3
ntp s'occupant de l'heure système, et pas de l'horloge matérielle. Après, si la source matérielle d'interruptions du timer est complètement en vrac, effectivement, le système risque d'avoir du mal à tenir la bonne heure...
Meme dans ce cas, ntp conserve la synchro en temps (a peu pres) reel ...
J'ai un PC qui, en "standard" (ie avec un ntpdate en cron une fois de temps en temps) perds dans les 5 minutes par heure .. Et qui n'a plus aucun soucis a partir du moment ou il y'a un ntp permanent qui tourne
ntp s'occupant de l'heure système, et pas de l'horloge matérielle.
Après, si la source matérielle d'interruptions du timer est complètement
en vrac, effectivement, le système risque d'avoir du mal à tenir la
bonne heure...
Meme dans ce cas, ntp conserve la synchro en temps (a peu pres) reel ...
J'ai un PC qui, en "standard" (ie avec un ntpdate en cron une fois de
temps en temps) perds dans les 5 minutes par heure .. Et qui n'a plus
aucun soucis a partir du moment ou il y'a un ntp permanent qui tourne
ntp s'occupant de l'heure système, et pas de l'horloge matérielle. Après, si la source matérielle d'interruptions du timer est complètement en vrac, effectivement, le système risque d'avoir du mal à tenir la bonne heure...
Meme dans ce cas, ntp conserve la synchro en temps (a peu pres) reel ...
J'ai un PC qui, en "standard" (ie avec un ntpdate en cron une fois de temps en temps) perds dans les 5 minutes par heure .. Et qui n'a plus aucun soucis a partir du moment ou il y'a un ntp permanent qui tourne
Sly
wrote:
monsieur n'a pas lu, ou n'a pas compris ce que j'ai écrit ou peut-etre ne connait pas netflow. en tout cas ta reponse n'a rien à avoir avec ce que j'ai écrit. ce que j'ai dit est qu'on passe de plus en plus des outils où "client" fait une requete sur "serveur" pour recevoir des données vers les outils où ex-"serveur" (qui devient client) envoit les données vers le ex-"client" (qui devient serveur). et j'ai donné exemple des protocoles que cisco a fait comme netflow où le routeur envoit les informations sur le trafic qui passe par le routeur au serveur netflow. de la meme maniere rtm, installé sur les serveurs, envoit les datas sur serveur rtm. tu peux trouver plein d'autres exemple avec ce mode de fonctionnement.
Qu'importe la méthode de suivi, faut-il encore que soit bien géré côté
analyse... C'est souvent là que le bas blesse sur les outils de monitoring.
monsieur veut tester une carte mere où ntp se casse les dents ? dés qu'on a à nouveau ce cas là, je te donnerai le root sur la machine.
Ah bah là je demande à voir également, ntp mettant comme dit par
d'autres l'heure système à jour sans la moindre intéraction avec le bios, c'est peut être pas niveau hardware qu'il y a un problème si ça passe pas. Est-ce que hwclock merde aussi de la même manière dans les 2 sens de synchro ? J'ai souvent vu des machines avoir un problème d'heure bios ( pas sur des serveurs récents ceci dit ), des machines retarder niveau heure, mais un serveur sur lequel ntp se vautre à mettre à jour l'heure système à cause d'un problème hardware, là c'est un peu tiré par les cheveux je trouve ( et encore plus que le problème se répète sur plusieurs configs ).
Murphy a peut être jeté son dévolu sur OVH après tout, ou alors le datacenter d'OVH véhicule des ondes électromagnétiques importantes qui vident les piles des cartes mères tout en perturbant le système d'horloge pour le système... Faudra envoyer Colombo ;)
Concernant le matos : Oui on peut avoir une merde sur du matos cher, le matos cher n'empêche pas les problèmes de composants qui claquent quand ils sont neufs et pas encore en prod, la différence c'est surtout qu'une carte mère Gigabyte ou MSI par exemple aura des problèmes plus facilement dans le temps là où une carte haut de gamme ne se détériorera pas avec les années. Ceci en fonction des composants, principalement les MOFSET qui sont le point critique souvent dans la qualité des composants d'une carte mère. Et là dessus ne viens pas affirmer que c'est kif kif entre les 2, ça n'a rien à voir.
Ce qui sera intéressant, c'est de faire un graph des pourcentages de pannes entre les 2 types de matos en fonction de leur durée de fonctionnement. Là tu te rendras compte que le taux de panne est parfois proche au départ, mais que dans le temps la différence se creuse nettement, justifiant le prix plus élevé. Mais bon après c'est un choix économique, remplacer une carte mère low cost de temps en temps coûte moins cher que d'acheter du bon matos, même en faisant parfois une bonne reduc au client mécontent de la coupure de service. Tu fais du bas prix, ça fait parti du deal et je critique pas, c'est un choix. Mais n'insinue pas que la différence est faible en fiabilité, ce serait un gros mensonge là qui ferait penser que tu cherches à valoriser ton matos low cost par rapport à du matos pro :/
En 10 ans d'expérience réelle dans le monde du matos PC ( on ne parle pas de quelques dizaines de machines bien entendu là ), je n'ai jamais eu de surprise à ce niveau là, le bon matos ça crame dans les premières semaines ou ça dure jusqu'à ce que ce soit obsolète pour ce type de composants. Il n'en est pas de même pour le matos de merde. D'où l'intérêt de faire tourner en burn du matos neuf pendant une période, quelque soit sa qualité, pour réduire les risques.
Cordialement,
Sly
P.S. : Pas que j'aime participer aux polémiques sur le newsgroup, mais le coup d'amalgammer bios, matériel, heure système et ntp sans détailler le processus qui a pu mener à une telle conclusion j'ai trouvé ça un peu fort désolé. Quand derrière on porte une analyse sur les pannes sans tenir compte de la variable temps et sans parler de la dégradation des composants différente selon la qualité dans la durée ( et ça c'est un fait avéré si si ), c'est un peu cheap pour étayer ces déclarations.
oles@ovh.net wrote:
monsieur n'a pas lu, ou n'a pas compris ce que j'ai écrit ou peut-etre
ne connait pas netflow. en tout cas ta reponse n'a rien à avoir avec
ce que j'ai écrit. ce que j'ai dit est qu'on passe de plus en plus
des outils où "client" fait une requete sur "serveur" pour recevoir
des données vers les outils où ex-"serveur" (qui devient client) envoit
les données vers le ex-"client" (qui devient serveur). et j'ai donné
exemple des protocoles que cisco a fait comme netflow où le routeur
envoit les informations sur le trafic qui passe par le routeur au
serveur netflow. de la meme maniere rtm, installé sur les serveurs,
envoit les datas sur serveur rtm. tu peux trouver plein d'autres
exemple avec ce mode de fonctionnement.
Qu'importe la méthode de suivi, faut-il encore que soit bien géré côté
analyse... C'est souvent là que le bas blesse sur les outils de monitoring.
monsieur veut tester une carte mere où ntp se casse les dents ? dés qu'on
a à nouveau ce cas là, je te donnerai le root sur la machine.
Ah bah là je demande à voir également, ntp mettant comme dit par
d'autres l'heure système à jour sans la moindre intéraction avec le
bios, c'est peut être pas niveau hardware qu'il y a un problème si ça
passe pas. Est-ce que hwclock merde aussi de la même manière dans les 2
sens de synchro ? J'ai souvent vu des machines avoir un problème d'heure
bios ( pas sur des serveurs récents ceci dit ), des machines retarder
niveau heure, mais un serveur sur lequel ntp se vautre à mettre à jour
l'heure système à cause d'un problème hardware, là c'est un peu tiré par
les cheveux je trouve ( et encore plus que le problème se répète sur
plusieurs configs ).
Murphy a peut être jeté son dévolu sur OVH après tout, ou alors le
datacenter d'OVH véhicule des ondes électromagnétiques importantes qui
vident les piles des cartes mères tout en perturbant le système
d'horloge pour le système... Faudra envoyer Colombo ;)
Concernant le matos : Oui on peut avoir une merde sur du matos cher, le
matos cher n'empêche pas les problèmes de composants qui claquent quand
ils sont neufs et pas encore en prod, la différence c'est surtout qu'une
carte mère Gigabyte ou MSI par exemple aura des problèmes plus
facilement dans le temps là où une carte haut de gamme ne se détériorera
pas avec les années. Ceci en fonction des composants, principalement les
MOFSET qui sont le point critique souvent dans la qualité des composants
d'une carte mère. Et là dessus ne viens pas affirmer que c'est kif kif
entre les 2, ça n'a rien à voir.
Ce qui sera intéressant, c'est de faire un graph des pourcentages de
pannes entre les 2 types de matos en fonction de leur durée de
fonctionnement. Là tu te rendras compte que le taux de panne est parfois
proche au départ, mais que dans le temps la différence se creuse
nettement, justifiant le prix plus élevé. Mais bon après c'est un choix
économique, remplacer une carte mère low cost de temps en temps coûte
moins cher que d'acheter du bon matos, même en faisant parfois une bonne
reduc au client mécontent de la coupure de service. Tu fais du bas prix,
ça fait parti du deal et je critique pas, c'est un choix. Mais n'insinue
pas que la différence est faible en fiabilité, ce serait un gros
mensonge là qui ferait penser que tu cherches à valoriser ton matos low
cost par rapport à du matos pro :/
En 10 ans d'expérience réelle dans le monde du matos PC ( on ne parle
pas de quelques dizaines de machines bien entendu là ), je n'ai jamais
eu de surprise à ce niveau là, le bon matos ça crame dans les premières
semaines ou ça dure jusqu'à ce que ce soit obsolète pour ce type de
composants. Il n'en est pas de même pour le matos de merde. D'où
l'intérêt de faire tourner en burn du matos neuf pendant une période,
quelque soit sa qualité, pour réduire les risques.
Cordialement,
Sly
P.S. : Pas que j'aime participer aux polémiques sur le newsgroup, mais
le coup d'amalgammer bios, matériel, heure système et ntp sans détailler
le processus qui a pu mener à une telle conclusion j'ai trouvé ça un peu
fort désolé. Quand derrière on porte une analyse sur les pannes sans
tenir compte de la variable temps et sans parler de la dégradation des
composants différente selon la qualité dans la durée ( et ça c'est un
fait avéré si si ), c'est un peu cheap pour étayer ces déclarations.
monsieur n'a pas lu, ou n'a pas compris ce que j'ai écrit ou peut-etre ne connait pas netflow. en tout cas ta reponse n'a rien à avoir avec ce que j'ai écrit. ce que j'ai dit est qu'on passe de plus en plus des outils où "client" fait une requete sur "serveur" pour recevoir des données vers les outils où ex-"serveur" (qui devient client) envoit les données vers le ex-"client" (qui devient serveur). et j'ai donné exemple des protocoles que cisco a fait comme netflow où le routeur envoit les informations sur le trafic qui passe par le routeur au serveur netflow. de la meme maniere rtm, installé sur les serveurs, envoit les datas sur serveur rtm. tu peux trouver plein d'autres exemple avec ce mode de fonctionnement.
Qu'importe la méthode de suivi, faut-il encore que soit bien géré côté
analyse... C'est souvent là que le bas blesse sur les outils de monitoring.
monsieur veut tester une carte mere où ntp se casse les dents ? dés qu'on a à nouveau ce cas là, je te donnerai le root sur la machine.
Ah bah là je demande à voir également, ntp mettant comme dit par
d'autres l'heure système à jour sans la moindre intéraction avec le bios, c'est peut être pas niveau hardware qu'il y a un problème si ça passe pas. Est-ce que hwclock merde aussi de la même manière dans les 2 sens de synchro ? J'ai souvent vu des machines avoir un problème d'heure bios ( pas sur des serveurs récents ceci dit ), des machines retarder niveau heure, mais un serveur sur lequel ntp se vautre à mettre à jour l'heure système à cause d'un problème hardware, là c'est un peu tiré par les cheveux je trouve ( et encore plus que le problème se répète sur plusieurs configs ).
Murphy a peut être jeté son dévolu sur OVH après tout, ou alors le datacenter d'OVH véhicule des ondes électromagnétiques importantes qui vident les piles des cartes mères tout en perturbant le système d'horloge pour le système... Faudra envoyer Colombo ;)
Concernant le matos : Oui on peut avoir une merde sur du matos cher, le matos cher n'empêche pas les problèmes de composants qui claquent quand ils sont neufs et pas encore en prod, la différence c'est surtout qu'une carte mère Gigabyte ou MSI par exemple aura des problèmes plus facilement dans le temps là où une carte haut de gamme ne se détériorera pas avec les années. Ceci en fonction des composants, principalement les MOFSET qui sont le point critique souvent dans la qualité des composants d'une carte mère. Et là dessus ne viens pas affirmer que c'est kif kif entre les 2, ça n'a rien à voir.
Ce qui sera intéressant, c'est de faire un graph des pourcentages de pannes entre les 2 types de matos en fonction de leur durée de fonctionnement. Là tu te rendras compte que le taux de panne est parfois proche au départ, mais que dans le temps la différence se creuse nettement, justifiant le prix plus élevé. Mais bon après c'est un choix économique, remplacer une carte mère low cost de temps en temps coûte moins cher que d'acheter du bon matos, même en faisant parfois une bonne reduc au client mécontent de la coupure de service. Tu fais du bas prix, ça fait parti du deal et je critique pas, c'est un choix. Mais n'insinue pas que la différence est faible en fiabilité, ce serait un gros mensonge là qui ferait penser que tu cherches à valoriser ton matos low cost par rapport à du matos pro :/
En 10 ans d'expérience réelle dans le monde du matos PC ( on ne parle pas de quelques dizaines de machines bien entendu là ), je n'ai jamais eu de surprise à ce niveau là, le bon matos ça crame dans les premières semaines ou ça dure jusqu'à ce que ce soit obsolète pour ce type de composants. Il n'en est pas de même pour le matos de merde. D'où l'intérêt de faire tourner en burn du matos neuf pendant une période, quelque soit sa qualité, pour réduire les risques.
Cordialement,
Sly
P.S. : Pas que j'aime participer aux polémiques sur le newsgroup, mais le coup d'amalgammer bios, matériel, heure système et ntp sans détailler le processus qui a pu mener à une telle conclusion j'ai trouvé ça un peu fort désolé. Quand derrière on porte une analyse sur les pannes sans tenir compte de la variable temps et sans parler de la dégradation des composants différente selon la qualité dans la durée ( et ça c'est un fait avéré si si ), c'est un peu cheap pour étayer ces déclarations.
Nicolas
"Sly" a écrit dans le message de news: 427d5fdb$0$307$
wrote: Ceci en fonction des composants, principalement les
MOFSET qui sont le point critique souvent dans la qualité des composants d'une carte mère. Et là dessus ne viens pas affirmer que c'est kif kif entre les 2, ça n'a rien à voir.
Les condensateurs chimiques aussi, qui si sont mal placés, à côté du processeur par exemple, chauffent , sèchent et rendent la carte mere hs au bout de 2 ans....
"Sly" <sly@_no-spam> a écrit dans le message de news:
427d5fdb$0$307$626a14ce@news.free.fr...
oles@ovh.net wrote:
Ceci en fonction des composants, principalement les
MOFSET qui sont le point critique souvent dans la qualité des composants
d'une carte mère. Et là dessus ne viens pas affirmer que c'est kif kif
entre les 2, ça n'a rien à voir.
Les condensateurs chimiques aussi, qui si sont mal placés, à côté du
processeur par exemple, chauffent , sèchent et rendent la carte mere hs au
bout de 2 ans....
"Sly" a écrit dans le message de news: 427d5fdb$0$307$
wrote: Ceci en fonction des composants, principalement les
MOFSET qui sont le point critique souvent dans la qualité des composants d'une carte mère. Et là dessus ne viens pas affirmer que c'est kif kif entre les 2, ça n'a rien à voir.
Les condensateurs chimiques aussi, qui si sont mal placés, à côté du processeur par exemple, chauffent , sèchent et rendent la carte mere hs au bout de 2 ans....
