sur un LAN d'une quinzaine de postes, j'ai peut-être des micro-coupures
de réseau.
Hors, comme ce serait des *micro*-coupures, un simple monitoring SNMP ne
révèle rien.
Comment procéder pour savoir si ces coupures existent vraiment (en
considérant qu'il y a quelques coupures/heure)?
J'ai pensé à acheter un bon testeur de câble avec reflectomètre, mais ça
coûte dans les 400 euros (voire bcp plus).
Donc déjà, est-ce que ce serait utile et, si oui, quel testeur prendre ?
Sinon comme savoir s'il y a ce problème ? (en fait, il s'agit d'une
application qui crash en indiquant qu'il y a eu un problème de liaison,
alors que tout fonctionne bien.)
mais j'ajouterais : le mode tcp est un protocole en mode connecté. de ce fait, le protocole lui même prend en charge certains problèmes réseaux.
entre autres (je ne me souviens plus de tout...) : - la remise en ordre des paquets reçus (oui, le paquet 36 peut arriver avec le 17). - la gestion des paquets perdus : hé...ho... il me manque le paquet 51 ! - la gestion des paquets corrompus. - ...
de par ces simples règles, une micro-coupure ne peut pas entraver le fonctionnement d'une application. tout au plus un léger ralentissement dû à la re-émission du paquet perdu ou corrompu pendant la micro-coupure... disons 0.1-0.5 micro seconde.
Je doute de cette valeur. Même en gigabit ethernet, la seule transmission physique d'une trame de 1500 octets prend plus de 10 µs, sans compter le temps de traitement par les OS, les cartes et les switches intermédiaires ni le temps de propagation le long des câbles. D'autre part, je n'ai jamais été très calé sur le protocole TCP, mais il me semble qu'il n'y a pas de mécanisme positif de signalisation par le destinataire à l'expéditeur de paquet perdu ou corrompu par la couche de liaison. La détection est réalisée par l'émetteur, par l'absence d'acquittement après un délai d'attente. Le temps de retransmission est donc plus ou moins lié à ce délai, qui est largement supérieur à la microseconde.
[Crosspost et suivi dans fr.comp.reseaux.ip]
tiens, il y en a un qui suit !
mais tu as tout à fait raison et c'est pluôt 0.1-0.5 milli secondes. j'ai un peu cafouiller entre micro coupure et milli seconde :)))
toutes mes excuses.
-- klp
In article <ep7rji$1q3c$1@biggoron.nerim.net>,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
Salut,
mais j'ajouterais : le mode tcp est un protocole en mode connecté. de ce
fait, le protocole lui même prend en charge certains problèmes réseaux.
entre autres (je ne me souviens plus de tout...) :
- la remise en ordre des paquets reçus (oui, le paquet 36 peut arriver
avec le 17).
- la gestion des paquets perdus : hé...ho... il me manque le paquet 51 !
- la gestion des paquets corrompus.
- ...
de par ces simples règles, une micro-coupure ne peut pas entraver le
fonctionnement d'une application. tout au plus un léger ralentissement
dû à la re-émission du paquet perdu ou corrompu pendant la
micro-coupure... disons 0.1-0.5 micro seconde.
Je doute de cette valeur. Même en gigabit ethernet, la seule
transmission physique d'une trame de 1500 octets prend plus de 10 µs,
sans compter le temps de traitement par les OS, les cartes et les
switches intermédiaires ni le temps de propagation le long des câbles.
D'autre part, je n'ai jamais été très calé sur le protocole TCP, mais il
me semble qu'il n'y a pas de mécanisme positif de signalisation par le
destinataire à l'expéditeur de paquet perdu ou corrompu par la couche de
liaison. La détection est réalisée par l'émetteur, par l'absence
d'acquittement après un délai d'attente. Le temps de retransmission est
donc plus ou moins lié à ce délai, qui est largement supérieur à la
microseconde.
[Crosspost et suivi dans fr.comp.reseaux.ip]
tiens, il y en a un qui suit !
mais tu as tout à fait raison et c'est pluôt 0.1-0.5 milli secondes.
j'ai un peu cafouiller entre micro coupure et milli seconde :)))
mais j'ajouterais : le mode tcp est un protocole en mode connecté. de ce fait, le protocole lui même prend en charge certains problèmes réseaux.
entre autres (je ne me souviens plus de tout...) : - la remise en ordre des paquets reçus (oui, le paquet 36 peut arriver avec le 17). - la gestion des paquets perdus : hé...ho... il me manque le paquet 51 ! - la gestion des paquets corrompus. - ...
de par ces simples règles, une micro-coupure ne peut pas entraver le fonctionnement d'une application. tout au plus un léger ralentissement dû à la re-émission du paquet perdu ou corrompu pendant la micro-coupure... disons 0.1-0.5 micro seconde.
Je doute de cette valeur. Même en gigabit ethernet, la seule transmission physique d'une trame de 1500 octets prend plus de 10 µs, sans compter le temps de traitement par les OS, les cartes et les switches intermédiaires ni le temps de propagation le long des câbles. D'autre part, je n'ai jamais été très calé sur le protocole TCP, mais il me semble qu'il n'y a pas de mécanisme positif de signalisation par le destinataire à l'expéditeur de paquet perdu ou corrompu par la couche de liaison. La détection est réalisée par l'émetteur, par l'absence d'acquittement après un délai d'attente. Le temps de retransmission est donc plus ou moins lié à ce délai, qui est largement supérieur à la microseconde.
[Crosspost et suivi dans fr.comp.reseaux.ip]
tiens, il y en a un qui suit !
mais tu as tout à fait raison et c'est pluôt 0.1-0.5 milli secondes. j'ai un peu cafouiller entre micro coupure et milli seconde :)))
toutes mes excuses.
-- klp
Olivier Masson
tiens, il y en a un qui suit !
mais tu as tout à fait raison et c'est pluôt 0.1-0.5 milli secondes. j'ai un peu cafouiller entre micro coupure et milli seconde :)))
toutes mes excuses.
Oui bon, quant à définir la durée d'une micro-coupure... Ce sont peut-être des macro-coupures à l'échelle TCP/IP. De toutes façons, si j'avais des trames réémises, l'interface du serveur me le dirait.
tiens, il y en a un qui suit !
mais tu as tout à fait raison et c'est pluôt 0.1-0.5 milli secondes.
j'ai un peu cafouiller entre micro coupure et milli seconde :)))
toutes mes excuses.
Oui bon, quant à définir la durée d'une micro-coupure... Ce sont
peut-être des macro-coupures à l'échelle TCP/IP.
De toutes façons, si j'avais des trames réémises, l'interface du serveur
me le dirait.
mais tu as tout à fait raison et c'est pluôt 0.1-0.5 milli secondes. j'ai un peu cafouiller entre micro coupure et milli seconde :)))
toutes mes excuses.
Oui bon, quant à définir la durée d'une micro-coupure... Ce sont peut-être des macro-coupures à l'échelle TCP/IP. De toutes façons, si j'avais des trames réémises, l'interface du serveur me le dirait.
Pascal Hambourg
De toutes façons, si j'avais des trames réémises, l'interface du serveur me le dirait.
Attention à faire la distinction entre les trames ethernet réémises (par exemple à cause d'une collision détectée) et les segments TCP réémis (car non acquittés à temps).
De toutes façons, si j'avais des trames réémises, l'interface du serveur
me le dirait.
Attention à faire la distinction entre les trames ethernet réémises (par
exemple à cause d'une collision détectée) et les segments TCP réémis
(car non acquittés à temps).
De toutes façons, si j'avais des trames réémises, l'interface du serveur me le dirait.
Attention à faire la distinction entre les trames ethernet réémises (par exemple à cause d'une collision détectée) et les segments TCP réémis (car non acquittés à temps).
Olivier Masson
Attention à faire la distinction entre les trames ethernet réémises (par exemple à cause d'une collision détectée) et les segments TCP réémis (car non acquittés à temps).
C'est pas le but du checksum offload de contrôler les pitis paquets ?
Attention à faire la distinction entre les trames ethernet réémises (par
exemple à cause d'une collision détectée) et les segments TCP réémis
(car non acquittés à temps).
C'est pas le but du checksum offload de contrôler les pitis paquets ?
Attention à faire la distinction entre les trames ethernet réémises (par exemple à cause d'une collision détectée) et les segments TCP réémis (car non acquittés à temps).
C'est pas le but du checksum offload de contrôler les pitis paquets ?
Pascal Hambourg
Attention à faire la distinction entre les trames ethernet réémises (par exemple à cause d'une collision détectée) et les segments TCP réémis (car non acquittés à temps).
C'est pas le but du checksum offload de contrôler les pitis paquets ?
En réception seulement, et le fait qu'il soit "offload" (géré par l'adaptateur ethernet et non par l'OS) ne change rien. Ça ne prévient pas l'émetteur si le paquet a été reçu en mauvais état, voire pas reçu du tout.
Attention à faire la distinction entre les trames ethernet réémises
(par exemple à cause d'une collision détectée) et les segments TCP
réémis (car non acquittés à temps).
C'est pas le but du checksum offload de contrôler les pitis paquets ?
En réception seulement, et le fait qu'il soit "offload" (géré par
l'adaptateur ethernet et non par l'OS) ne change rien. Ça ne prévient
pas l'émetteur si le paquet a été reçu en mauvais état, voire pas reçu
du tout.
Attention à faire la distinction entre les trames ethernet réémises (par exemple à cause d'une collision détectée) et les segments TCP réémis (car non acquittés à temps).
C'est pas le but du checksum offload de contrôler les pitis paquets ?
En réception seulement, et le fait qu'il soit "offload" (géré par l'adaptateur ethernet et non par l'OS) ne change rien. Ça ne prévient pas l'émetteur si le paquet a été reçu en mauvais état, voire pas reçu du tout.
Olivier Masson
En réception seulement, et le fait qu'il soit "offload" (géré par l'adaptateur ethernet et non par l'OS) ne change rien. Ça ne prévient pas l'émetteur si le paquet a été reçu en mauvais état, voire pas reçu du tout.
Pourtant j'ai la possibilité (que j'ai utilisée) de mettre le checksum offload en Tx/Rx. Ca ne prévient pas l'autre, mais ça le log, donc j'en aurais trace, non ?
En réception seulement, et le fait qu'il soit "offload" (géré par
l'adaptateur ethernet et non par l'OS) ne change rien. Ça ne prévient
pas l'émetteur si le paquet a été reçu en mauvais état, voire pas reçu
du tout.
Pourtant j'ai la possibilité (que j'ai utilisée) de mettre le checksum
offload en Tx/Rx.
Ca ne prévient pas l'autre, mais ça le log, donc j'en aurais trace, non ?
En réception seulement, et le fait qu'il soit "offload" (géré par l'adaptateur ethernet et non par l'OS) ne change rien. Ça ne prévient pas l'émetteur si le paquet a été reçu en mauvais état, voire pas reçu du tout.
Pourtant j'ai la possibilité (que j'ai utilisée) de mettre le checksum offload en Tx/Rx. Ca ne prévient pas l'autre, mais ça le log, donc j'en aurais trace, non ?
Pascal Hambourg
C'est pas le but du checksum offload de contrôler les pitis paquets ?
En réception seulement, et le fait qu'il soit "offload" (géré par l'adaptateur ethernet et non par l'OS) ne change rien. Ça ne prévient pas l'émetteur si le paquet a été reçu en mauvais état, voire pas reçu du tout.
Pourtant j'ai la possibilité (que j'ai utilisée) de mettre le checksum offload en Tx/Rx.
En émission (Tx), la carte calcule le checksum des trames émises. En réception (Rx), elle vérifie le checksum des trames reçues. En fait c'est quasiment la même opération.
Ca ne prévient pas l'autre, mais ça le log, donc j'en aurais trace, non ?
Si la trame en erreur atteint la carte. Si l'erreur se produit entre l'émetteur et le switch et que ce dernier n'est pas administrable, il va jeter la trame en erreur et le récepteur ne verra rien.
C'est pas le but du checksum offload de contrôler les pitis paquets ?
En réception seulement, et le fait qu'il soit "offload" (géré par
l'adaptateur ethernet et non par l'OS) ne change rien. Ça ne prévient
pas l'émetteur si le paquet a été reçu en mauvais état, voire pas reçu
du tout.
Pourtant j'ai la possibilité (que j'ai utilisée) de mettre le checksum
offload en Tx/Rx.
En émission (Tx), la carte calcule le checksum des trames émises. En
réception (Rx), elle vérifie le checksum des trames reçues. En fait
c'est quasiment la même opération.
Ca ne prévient pas l'autre, mais ça le log, donc j'en aurais trace, non ?
Si la trame en erreur atteint la carte. Si l'erreur se produit entre
l'émetteur et le switch et que ce dernier n'est pas administrable, il va
jeter la trame en erreur et le récepteur ne verra rien.
C'est pas le but du checksum offload de contrôler les pitis paquets ?
En réception seulement, et le fait qu'il soit "offload" (géré par l'adaptateur ethernet et non par l'OS) ne change rien. Ça ne prévient pas l'émetteur si le paquet a été reçu en mauvais état, voire pas reçu du tout.
Pourtant j'ai la possibilité (que j'ai utilisée) de mettre le checksum offload en Tx/Rx.
En émission (Tx), la carte calcule le checksum des trames émises. En réception (Rx), elle vérifie le checksum des trames reçues. En fait c'est quasiment la même opération.
Ca ne prévient pas l'autre, mais ça le log, donc j'en aurais trace, non ?
Si la trame en erreur atteint la carte. Si l'erreur se produit entre l'émetteur et le switch et que ce dernier n'est pas administrable, il va jeter la trame en erreur et le récepteur ne verra rien.
Olivier Masson
Si la trame en erreur atteint la carte. Si l'erreur se produit entre l'émetteur et le switch et que ce dernier n'est pas administrable, il va jeter la trame en erreur et le récepteur ne verra rien.
D'accord. C'est logique. Mais n'est-ce pas tout aussi logique de penser que, si micro-coupures il y a, elles provoquent des erreurs de trames dans les deux sens. Donc, je ne vois pas les erreurs de transmission à l'autre bout mais je vois les erreurs de transmission de mon serveur. Bon ?
Si la trame en erreur atteint la carte. Si l'erreur se produit entre
l'émetteur et le switch et que ce dernier n'est pas administrable, il va
jeter la trame en erreur et le récepteur ne verra rien.
D'accord. C'est logique. Mais n'est-ce pas tout aussi logique de penser
que, si micro-coupures il y a, elles provoquent des erreurs de trames
dans les deux sens. Donc, je ne vois pas les erreurs de transmission à
l'autre bout mais je vois les erreurs de transmission de mon serveur. Bon ?
Si la trame en erreur atteint la carte. Si l'erreur se produit entre l'émetteur et le switch et que ce dernier n'est pas administrable, il va jeter la trame en erreur et le récepteur ne verra rien.
D'accord. C'est logique. Mais n'est-ce pas tout aussi logique de penser que, si micro-coupures il y a, elles provoquent des erreurs de trames dans les deux sens. Donc, je ne vois pas les erreurs de transmission à l'autre bout mais je vois les erreurs de transmission de mon serveur. Bon ?
Pascal Hambourg
Si la trame en erreur atteint la carte. Si l'erreur se produit entre l'émetteur et le switch et que ce dernier n'est pas administrable, il va jeter la trame en erreur et le récepteur ne verra rien.
Bien entendu un switch store-and-forward jette les trames reçues en erreur qu'il soit administrable ou non. Mais je voulais dire qu'un switch administrable peut en garder une trace, contrairement à un switch non administrable.
D'accord. C'est logique. Mais n'est-ce pas tout aussi logique de penser que, si micro-coupures il y a, elles provoquent des erreurs de trames dans les deux sens. Donc, je ne vois pas les erreurs de transmission à l'autre bout mais je vois les erreurs de transmission de mon serveur. Bon ?
C'est possible, mais pas certain. Les erreurs peuvent ne se produire que dans un sens en raison de dissymétries de la liaison : - différence de taille des paquets (données dans un sens, acquittements dans l'autre) - défaut dans le câblage d'une des paires (si 10Base-T/100Base-TX) - incompatibilité entre un récepteur et un émetteur.
[Comme ça repart sur ethernet, je redirige dans le forum de départ]
Si la trame en erreur atteint la carte. Si l'erreur se produit entre
l'émetteur et le switch et que ce dernier n'est pas administrable, il
va jeter la trame en erreur et le récepteur ne verra rien.
Bien entendu un switch store-and-forward jette les trames reçues en
erreur qu'il soit administrable ou non. Mais je voulais dire qu'un
switch administrable peut en garder une trace, contrairement à un switch
non administrable.
D'accord. C'est logique. Mais n'est-ce pas tout aussi logique de penser
que, si micro-coupures il y a, elles provoquent des erreurs de trames
dans les deux sens. Donc, je ne vois pas les erreurs de transmission à
l'autre bout mais je vois les erreurs de transmission de mon serveur. Bon ?
C'est possible, mais pas certain. Les erreurs peuvent ne se produire que
dans un sens en raison de dissymétries de la liaison :
- différence de taille des paquets (données dans un sens, acquittements
dans l'autre)
- défaut dans le câblage d'une des paires (si 10Base-T/100Base-TX)
- incompatibilité entre un récepteur et un émetteur.
[Comme ça repart sur ethernet, je redirige dans le forum de départ]
Si la trame en erreur atteint la carte. Si l'erreur se produit entre l'émetteur et le switch et que ce dernier n'est pas administrable, il va jeter la trame en erreur et le récepteur ne verra rien.
Bien entendu un switch store-and-forward jette les trames reçues en erreur qu'il soit administrable ou non. Mais je voulais dire qu'un switch administrable peut en garder une trace, contrairement à un switch non administrable.
D'accord. C'est logique. Mais n'est-ce pas tout aussi logique de penser que, si micro-coupures il y a, elles provoquent des erreurs de trames dans les deux sens. Donc, je ne vois pas les erreurs de transmission à l'autre bout mais je vois les erreurs de transmission de mon serveur. Bon ?
C'est possible, mais pas certain. Les erreurs peuvent ne se produire que dans un sens en raison de dissymétries de la liaison : - différence de taille des paquets (données dans un sens, acquittements dans l'autre) - défaut dans le câblage d'une des paires (si 10Base-T/100Base-TX) - incompatibilité entre un récepteur et un émetteur.
[Comme ça repart sur ethernet, je redirige dans le forum de départ]
