bonsoir à tous
y a t'il un freeware qui affiche le nombre de répetitions de trames IP
?
sinon inclus dans Ethereal, Winlan ou autre ?
ce serait pour voir l'effet de la modification de la MTU
merci d'avance
y a t'il un freeware qui affiche le nombre de répetitions de trames IP ?
Jamais entendu parler de "trames IP", moi... :-P
sinon inclus dans Ethereal, Winlan ou autre ? ce serait pour voir l'effet de la modification de la MTU merci d'avance
Suffit de regarder la capture avec un utilitaire de type Wireshark...
Cordialement, Mateusz VISTE
bpdu92
On Sun, 08 Feb 2009 09:58:03 +0100, Mateusz Viste wrote:
On Sunday 08 February 2009 03:19, bpdu92 wrote:
y a t'il un freeware qui affiche le nombre de répetitions de trames IP ?
Jamais entendu parler de "trames IP", moi... :-P
ben si tu demandes 'trame IP' à Google, ya que 172.000 réponses ? tu preferres quoi ? bloc ? datagramme ? paquet ? autre ?
sinon inclus dans Ethereal, Winlan ou autre ? ce serait pour voir l'effet de la modification de la MTU merci d'avance
Suffit de regarder la capture avec un utilitaire de type Wireshark...
-merci pour l'info, je savais pas que Ethereal avait changé de nom
-d'aprés la Faq http://www.wireshark.org/faq.html, Q 7.9, il semble que c'est pas possible, la couche pcap ne fournit pas les paquets avec CRC errors à Ethereal, ceci en reception, et en emission, je vois pas où il indique les retries ?
Cordialement,
au plaisir de te lire
Mateusz VISTE
suisse ?
On Sun, 08 Feb 2009 09:58:03 +0100, Mateusz Viste
<mateuszATviste-familyDOTnet@localhost.localhost> wrote:
On Sunday 08 February 2009 03:19, bpdu92 wrote:
y a t'il un freeware qui affiche le nombre de répetitions de trames IP
?
Jamais entendu parler de "trames IP", moi... :-P
ben si tu demandes 'trame IP' à Google, ya que 172.000 réponses ?
tu preferres quoi ? bloc ? datagramme ? paquet ? autre ?
sinon inclus dans Ethereal, Winlan ou autre ?
ce serait pour voir l'effet de la modification de la MTU
merci d'avance
Suffit de regarder la capture avec un utilitaire de type Wireshark...
-merci pour l'info, je savais pas que Ethereal avait changé de nom
-d'aprés la Faq http://www.wireshark.org/faq.html, Q 7.9,
il semble que c'est pas possible, la couche pcap ne fournit pas
les paquets avec CRC errors à Ethereal, ceci en reception,
et en emission, je vois pas où il indique les retries ?
On Sun, 08 Feb 2009 09:58:03 +0100, Mateusz Viste wrote:
On Sunday 08 February 2009 03:19, bpdu92 wrote:
y a t'il un freeware qui affiche le nombre de répetitions de trames IP ?
Jamais entendu parler de "trames IP", moi... :-P
ben si tu demandes 'trame IP' à Google, ya que 172.000 réponses ? tu preferres quoi ? bloc ? datagramme ? paquet ? autre ?
sinon inclus dans Ethereal, Winlan ou autre ? ce serait pour voir l'effet de la modification de la MTU merci d'avance
Suffit de regarder la capture avec un utilitaire de type Wireshark...
-merci pour l'info, je savais pas que Ethereal avait changé de nom
-d'aprés la Faq http://www.wireshark.org/faq.html, Q 7.9, il semble que c'est pas possible, la couche pcap ne fournit pas les paquets avec CRC errors à Ethereal, ceci en reception, et en emission, je vois pas où il indique les retries ?
Cordialement,
au plaisir de te lire
Mateusz VISTE
suisse ?
Pascal Hambourg
Salut,
bpdu92 a écrit :
On Sunday 08 February 2009 03:19, bpdu92 wrote:
y a t'il un freeware qui affiche le nombre de répetitions de trames IP ?
Qu'entends-tu exactement par "répétitions" ?
-d'aprés la Faq http://www.wireshark.org/faq.html, Q 7.9, il semble que c'est pas possible, la couche pcap ne fournit pas les paquets avec CRC errors à Ethereal, ceci en reception, et en emission, je vois pas où il indique les retries ?
De quel CRC parles-tu ? FCS ethernet ? Checksum d'en-tête IP, TCP, UDP ?
Salut,
bpdu92 a écrit :
On Sunday 08 February 2009 03:19, bpdu92 wrote:
y a t'il un freeware qui affiche le nombre de répetitions de trames IP
?
Qu'entends-tu exactement par "répétitions" ?
-d'aprés la Faq http://www.wireshark.org/faq.html, Q 7.9,
il semble que c'est pas possible, la couche pcap ne fournit pas
les paquets avec CRC errors à Ethereal, ceci en reception,
et en emission, je vois pas où il indique les retries ?
De quel CRC parles-tu ? FCS ethernet ? Checksum d'en-tête IP, TCP, UDP ?
y a t'il un freeware qui affiche le nombre de répetitions de trames IP ?
Qu'entends-tu exactement par "répétitions" ?
-d'aprés la Faq http://www.wireshark.org/faq.html, Q 7.9, il semble que c'est pas possible, la couche pcap ne fournit pas les paquets avec CRC errors à Ethereal, ceci en reception, et en emission, je vois pas où il indique les retries ?
De quel CRC parles-tu ? FCS ethernet ? Checksum d'en-tête IP, TCP, UDP ?
bpdu92
On Sun, 08 Feb 2009 13:00:16 +0100, Pascal Hambourg wrote: salut Pascal
Salut,
bpdu92 a écrit :
On Sunday 08 February 2009 03:19, bpdu92 wrote:
y a t'il un freeware qui affiche le nombre de répetitions de trames IP ?
Qu'entends-tu exactement par "répétitions" ?
dans le cas où je suis l'emetteur, je répète un certain nb de fois si je n'ai pas l'accusé de reception de mon correspondant
-d'aprés la Faq http://www.wireshark.org/faq.html, Q 7.9, il semble que c'est pas possible, la couche pcap ne fournit pas les paquets avec CRC errors à Ethereal, ceci en reception, et en emission, je vois pas où il indique les retries ?
De quel CRC parles-tu ? FCS ethernet ? Checksum d'en-tête IP, TCP, UDP ?
tous ceux qui obligent mon correspondant à réemettre
c'est l'ensemble des 2 cas d'erreurs pour lequels je cherche un freeware, qui m'aiderait de façon quantitative à regler le mtu
TCP Optimizer me botte : il détaille pas les erreurs, il essaie tout seul différentes longueurs, et donne sa préférence
cordialt
On Sun, 08 Feb 2009 13:00:16 +0100, Pascal Hambourg
<boite-a-spam@plouf.fr.eu.org> wrote:
salut Pascal
Salut,
bpdu92 a écrit :
On Sunday 08 February 2009 03:19, bpdu92 wrote:
y a t'il un freeware qui affiche le nombre de répetitions de trames IP
?
Qu'entends-tu exactement par "répétitions" ?
dans le cas où je suis l'emetteur,
je répète un certain nb de fois si je n'ai pas l'accusé de reception
de mon correspondant
-d'aprés la Faq http://www.wireshark.org/faq.html, Q 7.9,
il semble que c'est pas possible, la couche pcap ne fournit pas
les paquets avec CRC errors à Ethereal, ceci en reception,
et en emission, je vois pas où il indique les retries ?
De quel CRC parles-tu ? FCS ethernet ? Checksum d'en-tête IP, TCP, UDP ?
tous ceux qui obligent mon correspondant à réemettre
c'est l'ensemble des 2 cas d'erreurs pour lequels je cherche un
freeware, qui m'aiderait de façon quantitative à regler le mtu
TCP Optimizer me botte : il détaille pas les erreurs,
il essaie tout seul différentes longueurs,
et donne sa préférence
On Sun, 08 Feb 2009 13:00:16 +0100, Pascal Hambourg wrote: salut Pascal
Salut,
bpdu92 a écrit :
On Sunday 08 February 2009 03:19, bpdu92 wrote:
y a t'il un freeware qui affiche le nombre de répetitions de trames IP ?
Qu'entends-tu exactement par "répétitions" ?
dans le cas où je suis l'emetteur, je répète un certain nb de fois si je n'ai pas l'accusé de reception de mon correspondant
-d'aprés la Faq http://www.wireshark.org/faq.html, Q 7.9, il semble que c'est pas possible, la couche pcap ne fournit pas les paquets avec CRC errors à Ethereal, ceci en reception, et en emission, je vois pas où il indique les retries ?
De quel CRC parles-tu ? FCS ethernet ? Checksum d'en-tête IP, TCP, UDP ?
tous ceux qui obligent mon correspondant à réemettre
c'est l'ensemble des 2 cas d'erreurs pour lequels je cherche un freeware, qui m'aiderait de façon quantitative à regler le mtu
TCP Optimizer me botte : il détaille pas les erreurs, il essaie tout seul différentes longueurs, et donne sa préférence
cordialt
Pascal Hambourg
bpdu92 a écrit :
dans le cas où je suis l'emetteur, je répète un certain nb de fois si je n'ai pas l'accusé de reception de mon correspondant
Si tu es l'émetteur, tu dois bien savoir combien de fois tu répètes ?
-d'aprés la Faq http://www.wireshark.org/faq.html, Q 7.9, il semble que c'est pas possible, la couche pcap ne fournit pas les paquets avec CRC errors à Ethereal, ceci en reception,
Faut dire qu'en émission il y a peu de chance d'y avoir des erreurs, et en réception je ne garantirais pas que le pilote de l'adaptateur ethernet voire l'adaptateur lui-même livre les trames avec une erreur de FCS à la couche supérieure. En revanche je ne vois pas pourquoi pcap ne fournirait pas les paquets reçus avec une erreur de checksum de couche supérieure (IP, TCP, UDP, ICMP...).
et en emission, je vois pas où il indique les retries ?
De quel CRC parles-tu ? FCS ethernet ? Checksum d'en-tête IP, TCP, UDP ?
tous ceux qui obligent mon correspondant à réemettre
Attention, il n'y a pas d'accusé de réception ni de mécanisme de retransmission systématique en ethernet, IP ou UDP, ni de signalement d'une erreur de checksum à l'émetteur. En UDP, c'est à la couche applicative de retransmettre si elle l'estime nécessaire. Seuls TCP et autres protocoles du même type ont un mécanisme de retransmission. Mais l'erreur de checksum n'est pas la seule cause de retransmission, il y a bien d'autres raisons qui peuvent faire qu'un paquet n'arrive pas à destination, notamment la congestion.
c'est l'ensemble des 2 cas d'erreurs pour lequels je cherche un freeware, qui m'aiderait de façon quantitative à regler le mtu
TCP Optimizer me botte : il détaille pas les erreurs, il essaie tout seul différentes longueurs, et donne sa préférence
S'il mesure le débit en TCP pour chaque valeur et si tu cherches à optimiser le débit en TCP en tenant compte du taux d'erreurs de transmission, alors ça me semble être une bonne approche pleine de pragmatisme.
Par curiosité, quelle est donc cette liaison dont le taux d'erreur de transmission est tel qu'il nécessiterait une réduction du MTU ?
bpdu92 a écrit :
dans le cas où je suis l'emetteur,
je répète un certain nb de fois si je n'ai pas l'accusé de reception
de mon correspondant
Si tu es l'émetteur, tu dois bien savoir combien de fois tu répètes ?
-d'aprés la Faq http://www.wireshark.org/faq.html, Q 7.9,
il semble que c'est pas possible, la couche pcap ne fournit pas
les paquets avec CRC errors à Ethereal, ceci en reception,
Faut dire qu'en émission il y a peu de chance d'y avoir des erreurs, et
en réception je ne garantirais pas que le pilote de l'adaptateur
ethernet voire l'adaptateur lui-même livre les trames avec une erreur de
FCS à la couche supérieure. En revanche je ne vois pas pourquoi pcap ne
fournirait pas les paquets reçus avec une erreur de checksum de couche
supérieure (IP, TCP, UDP, ICMP...).
et en emission, je vois pas où il indique les retries ?
De quel CRC parles-tu ? FCS ethernet ? Checksum d'en-tête IP, TCP, UDP ?
tous ceux qui obligent mon correspondant à réemettre
Attention, il n'y a pas d'accusé de réception ni de mécanisme de
retransmission systématique en ethernet, IP ou UDP, ni de signalement
d'une erreur de checksum à l'émetteur. En UDP, c'est à la couche
applicative de retransmettre si elle l'estime nécessaire. Seuls TCP et
autres protocoles du même type ont un mécanisme de retransmission. Mais
l'erreur de checksum n'est pas la seule cause de retransmission, il y a
bien d'autres raisons qui peuvent faire qu'un paquet n'arrive pas à
destination, notamment la congestion.
c'est l'ensemble des 2 cas d'erreurs pour lequels je cherche un
freeware, qui m'aiderait de façon quantitative à regler le mtu
TCP Optimizer me botte : il détaille pas les erreurs,
il essaie tout seul différentes longueurs,
et donne sa préférence
S'il mesure le débit en TCP pour chaque valeur et si tu cherches à
optimiser le débit en TCP en tenant compte du taux d'erreurs de
transmission, alors ça me semble être une bonne approche pleine de
pragmatisme.
Par curiosité, quelle est donc cette liaison dont le taux d'erreur de
transmission est tel qu'il nécessiterait une réduction du MTU ?
dans le cas où je suis l'emetteur, je répète un certain nb de fois si je n'ai pas l'accusé de reception de mon correspondant
Si tu es l'émetteur, tu dois bien savoir combien de fois tu répètes ?
-d'aprés la Faq http://www.wireshark.org/faq.html, Q 7.9, il semble que c'est pas possible, la couche pcap ne fournit pas les paquets avec CRC errors à Ethereal, ceci en reception,
Faut dire qu'en émission il y a peu de chance d'y avoir des erreurs, et en réception je ne garantirais pas que le pilote de l'adaptateur ethernet voire l'adaptateur lui-même livre les trames avec une erreur de FCS à la couche supérieure. En revanche je ne vois pas pourquoi pcap ne fournirait pas les paquets reçus avec une erreur de checksum de couche supérieure (IP, TCP, UDP, ICMP...).
et en emission, je vois pas où il indique les retries ?
De quel CRC parles-tu ? FCS ethernet ? Checksum d'en-tête IP, TCP, UDP ?
tous ceux qui obligent mon correspondant à réemettre
Attention, il n'y a pas d'accusé de réception ni de mécanisme de retransmission systématique en ethernet, IP ou UDP, ni de signalement d'une erreur de checksum à l'émetteur. En UDP, c'est à la couche applicative de retransmettre si elle l'estime nécessaire. Seuls TCP et autres protocoles du même type ont un mécanisme de retransmission. Mais l'erreur de checksum n'est pas la seule cause de retransmission, il y a bien d'autres raisons qui peuvent faire qu'un paquet n'arrive pas à destination, notamment la congestion.
c'est l'ensemble des 2 cas d'erreurs pour lequels je cherche un freeware, qui m'aiderait de façon quantitative à regler le mtu
TCP Optimizer me botte : il détaille pas les erreurs, il essaie tout seul différentes longueurs, et donne sa préférence
S'il mesure le débit en TCP pour chaque valeur et si tu cherches à optimiser le débit en TCP en tenant compte du taux d'erreurs de transmission, alors ça me semble être une bonne approche pleine de pragmatisme.
Par curiosité, quelle est donc cette liaison dont le taux d'erreur de transmission est tel qu'il nécessiterait une réduction du MTU ?
Stephane Bortzmeyer
bpdu92 wrote:
je répète un certain nb de fois si je n'ai pas l'accusé de reception de mon correspondant
Mais cela n'a rien à voir avec des erreurs de transmission. La plupart du temps, c'est la congestion qui fait que le routeur laisse tomber des paquets.
De quel CRC parles-tu ? FCS ethernet ? Checksum d'en-tête IP, TCP, UDP ?
tous ceux qui obligent mon correspondant à réemettre
Cf. ci-dessus. Sur les réseaux modernes, à part peut-être les liens radios, les erreurs de transmission sont rares (c'est une des raisons pour lesquelles la somme de contrôle IP qui existait en IPv4 a disparu en IPv6).
c'est l'ensemble des 2 cas d'erreurs pour lequels je cherche un freeware, qui m'aiderait de façon quantitative à regler le mtu
Mais quel rapport entre MTU et nombre d'erreurs de transmission ? Ou alors c'est sur des liens catastrophiques (liens radios à grande distance), où le teux d'erreurs est tel qu'il vaut parfois mieux réduire la MTU.
TCP Optimizer me botte : il détaille pas les erreurs, il essaie tout seul différentes longueurs, et donne sa préférence
Cf. RFC 4821 <http://www.bortzmeyer.org/4821.html>, qui préconise une méthode de ce genre.
bpdu92 wrote:
je répète un certain nb de fois si je n'ai pas l'accusé de reception
de mon correspondant
Mais cela n'a rien à voir avec des erreurs de transmission. La plupart
du temps, c'est la congestion qui fait que le routeur laisse tomber des
paquets.
De quel CRC parles-tu ? FCS ethernet ? Checksum d'en-tête IP, TCP, UDP ?
tous ceux qui obligent mon correspondant à réemettre
Cf. ci-dessus. Sur les réseaux modernes, à part peut-être les liens
radios, les erreurs de transmission sont rares (c'est une des raisons
pour lesquelles la somme de contrôle IP qui existait en IPv4 a disparu
en IPv6).
c'est l'ensemble des 2 cas d'erreurs pour lequels je cherche un
freeware, qui m'aiderait de façon quantitative à regler le mtu
Mais quel rapport entre MTU et nombre d'erreurs de transmission ? Ou
alors c'est sur des liens catastrophiques (liens radios à grande
distance), où le teux d'erreurs est tel qu'il vaut parfois mieux réduire
la MTU.
TCP Optimizer me botte : il détaille pas les erreurs,
il essaie tout seul différentes longueurs,
et donne sa préférence
Cf. RFC 4821 <http://www.bortzmeyer.org/4821.html>, qui préconise une
méthode de ce genre.
je répète un certain nb de fois si je n'ai pas l'accusé de reception de mon correspondant
Mais cela n'a rien à voir avec des erreurs de transmission. La plupart du temps, c'est la congestion qui fait que le routeur laisse tomber des paquets.
De quel CRC parles-tu ? FCS ethernet ? Checksum d'en-tête IP, TCP, UDP ?
tous ceux qui obligent mon correspondant à réemettre
Cf. ci-dessus. Sur les réseaux modernes, à part peut-être les liens radios, les erreurs de transmission sont rares (c'est une des raisons pour lesquelles la somme de contrôle IP qui existait en IPv4 a disparu en IPv6).
c'est l'ensemble des 2 cas d'erreurs pour lequels je cherche un freeware, qui m'aiderait de façon quantitative à regler le mtu
Mais quel rapport entre MTU et nombre d'erreurs de transmission ? Ou alors c'est sur des liens catastrophiques (liens radios à grande distance), où le teux d'erreurs est tel qu'il vaut parfois mieux réduire la MTU.
TCP Optimizer me botte : il détaille pas les erreurs, il essaie tout seul différentes longueurs, et donne sa préférence
Cf. RFC 4821 <http://www.bortzmeyer.org/4821.html>, qui préconise une méthode de ce genre.
Michelot
Bonjour Stéphane,
Cf. ci-dessus. Sur les réseaux modernes, à part peut-être les liens radios, les erreurs de transmission sont rares (c'est une des raisons pour lesquelles la somme de contrôle IP qui existait en IPv4 a disparu en IPv6).
Lorsque les signaux parcourent les fibres optiques des réseaux de transport, un résiduel de taux d'erreur bit de 10^-10 à 10^-9 existe, sans parler des coupures de liaisons, des glissements de trames, des bascules de synchronisation, des répétitions de trames... Le résiduel est normalement corrigé par les codages de Reed-Solomon, mais pas toujours.
Cordialement, Michelot
Bonjour Stéphane,
Cf. ci-dessus. Sur les réseaux modernes, à part peut-être les liens
radios, les erreurs de transmission sont rares (c'est une des raisons
pour lesquelles la somme de contrôle IP qui existait en IPv4 a disparu
en IPv6).
Lorsque les signaux parcourent les fibres optiques des réseaux de
transport, un résiduel de taux d'erreur bit de 10^-10 à 10^-9 existe,
sans parler des coupures de liaisons, des glissements de trames, des
bascules de synchronisation, des répétitions de trames... Le résiduel
est normalement corrigé par les codages de Reed-Solomon, mais pas
toujours.
Cf. ci-dessus. Sur les réseaux modernes, à part peut-être les liens radios, les erreurs de transmission sont rares (c'est une des raisons pour lesquelles la somme de contrôle IP qui existait en IPv4 a disparu en IPv6).
Lorsque les signaux parcourent les fibres optiques des réseaux de transport, un résiduel de taux d'erreur bit de 10^-10 à 10^-9 existe, sans parler des coupures de liaisons, des glissements de trames, des bascules de synchronisation, des répétitions de trames... Le résiduel est normalement corrigé par les codages de Reed-Solomon, mais pas toujours.
Cordialement, Michelot
bpdu92
On Sun, 08 Feb 2009 19:53:30 +0100, Pascal Hambourg wrote:
Par curiosité, quelle est donc cette liaison dont le taux d'erreur de transmission est tel qu'il nécessiterait une réduction du MTU ?
c'est une liaison Orange dans Paris 16eme un peu bizarre : même aprés reduction (par la HotLine Orange) du débit de 18 à 8 Mbps,il était impossible d'aller sur certains sites, par ex Boursorama et Yahoo, alors que d'autres, par ex les pages Google étaient accédés sans pb
aprés réduction de MTU à 1400, au lieu de 1500, tout est redevenu ok, sauf DSLtest qui continue à dire que la ligne n'existe pas ??
pour pas mourir idiot, mon post cherche donc à connaitre les taux d'erreurs selon la taille du mtu, mais peut-être est-ce simplement la 1ere grosse trame, à 1500 octets sui n'arrive pas à passer ? Google passe car il n'emet pas de grosses trames ? merci
On Sun, 08 Feb 2009 19:53:30 +0100, Pascal Hambourg
<boite-a-spam@plouf.fr.eu.org> wrote:
Par curiosité, quelle est donc cette liaison dont le taux d'erreur de
transmission est tel qu'il nécessiterait une réduction du MTU ?
c'est une liaison Orange dans Paris 16eme un peu bizarre :
même aprés reduction (par la HotLine Orange) du débit
de 18 à 8 Mbps,il était impossible d'aller sur certains sites,
par ex Boursorama et Yahoo,
alors que d'autres, par ex les pages Google étaient accédés sans pb
aprés réduction de MTU à 1400, au lieu de 1500, tout est redevenu ok,
sauf DSLtest qui continue à dire que la ligne n'existe pas ??
pour pas mourir idiot, mon post cherche donc à connaitre
les taux d'erreurs selon la taille du mtu,
mais peut-être est-ce simplement la 1ere grosse trame, à 1500 octets
sui n'arrive pas à passer ?
Google passe car il n'emet pas de grosses trames ?
merci
On Sun, 08 Feb 2009 19:53:30 +0100, Pascal Hambourg wrote:
Par curiosité, quelle est donc cette liaison dont le taux d'erreur de transmission est tel qu'il nécessiterait une réduction du MTU ?
c'est une liaison Orange dans Paris 16eme un peu bizarre : même aprés reduction (par la HotLine Orange) du débit de 18 à 8 Mbps,il était impossible d'aller sur certains sites, par ex Boursorama et Yahoo, alors que d'autres, par ex les pages Google étaient accédés sans pb
aprés réduction de MTU à 1400, au lieu de 1500, tout est redevenu ok, sauf DSLtest qui continue à dire que la ligne n'existe pas ??
pour pas mourir idiot, mon post cherche donc à connaitre les taux d'erreurs selon la taille du mtu, mais peut-être est-ce simplement la 1ere grosse trame, à 1500 octets sui n'arrive pas à passer ? Google passe car il n'emet pas de grosses trames ? merci
bpdu92
On Sun, 08 Feb 2009 22:14:58 +0100, Stephane Bortzmeyer wrote:
Mais quel rapport entre MTU et nombre d'erreurs de transmission ? Ou alors c'est sur des liens catastrophiques (liens radios à grande distance), où le teux d'erreurs est tel qu'il vaut parfois mieux réduire la MTU.
voir post précédent en réponse à Pascal, je n'ai pas de preuve qu'il s'agit d'erreurs de transmission, de trames droppées à cause de congestion, ou autre cas d'erreur, simplement ça ne passait pas sur certains sites avant de reduire le mtu
TCP Optimizer me botte : il détaille pas les erreurs, il essaie tout seul différentes longueurs, et donne sa préférence
Cf. RFC 4821 <http://www.bortzmeyer.org/4821.html>, qui préconise une méthode de ce genre.
ya une implémentation pour Windows ? ce RFC (d'accord, je devrais le lire) distingue t'il les clients et les box ? merci
On Sun, 08 Feb 2009 22:14:58 +0100, Stephane Bortzmeyer
<stephane@sources.org> wrote:
Mais quel rapport entre MTU et nombre d'erreurs de transmission ? Ou
alors c'est sur des liens catastrophiques (liens radios à grande
distance), où le teux d'erreurs est tel qu'il vaut parfois mieux réduire
la MTU.
voir post précédent en réponse à Pascal, je n'ai pas de preuve qu'il
s'agit d'erreurs de transmission, de trames droppées à cause de
congestion, ou autre cas d'erreur, simplement ça ne passait pas sur
certains sites avant de reduire le mtu
TCP Optimizer me botte : il détaille pas les erreurs,
il essaie tout seul différentes longueurs,
et donne sa préférence
Cf. RFC 4821 <http://www.bortzmeyer.org/4821.html>, qui préconise une
méthode de ce genre.
ya une implémentation pour Windows ?
ce RFC (d'accord, je devrais le lire) distingue t'il les clients et
les box ?
merci
On Sun, 08 Feb 2009 22:14:58 +0100, Stephane Bortzmeyer wrote:
Mais quel rapport entre MTU et nombre d'erreurs de transmission ? Ou alors c'est sur des liens catastrophiques (liens radios à grande distance), où le teux d'erreurs est tel qu'il vaut parfois mieux réduire la MTU.
voir post précédent en réponse à Pascal, je n'ai pas de preuve qu'il s'agit d'erreurs de transmission, de trames droppées à cause de congestion, ou autre cas d'erreur, simplement ça ne passait pas sur certains sites avant de reduire le mtu
TCP Optimizer me botte : il détaille pas les erreurs, il essaie tout seul différentes longueurs, et donne sa préférence
Cf. RFC 4821 <http://www.bortzmeyer.org/4821.html>, qui préconise une méthode de ce genre.
ya une implémentation pour Windows ? ce RFC (d'accord, je devrais le lire) distingue t'il les clients et les box ? merci
Pascal Hambourg
bpdu92 a écrit :
On Sun, 08 Feb 2009 19:53:30 +0100, Pascal Hambourg wrote:
Par curiosité, quelle est donc cette liaison dont le taux d'erreur de transmission est tel qu'il nécessiterait une réduction du MTU ?
c'est une liaison Orange dans Paris 16eme un peu bizarre :
Une liaison ADSL ? PPPoE ou PPPoA ?
même aprés reduction (par la HotLine Orange) du débit de 18 à 8 Mbps,il était impossible d'aller sur certains sites, par ex Boursorama et Yahoo, alors que d'autres, par ex les pages Google étaient accédés sans pb
aprés réduction de MTU à 1400, au lieu de 1500, tout est redevenu ok,
Problème de MTU a priori, surtout si c'est du tout ou rien. Je ne vois pas ce qui te fais penser à des erreurs de transmission en ligne, surtout si la diminution drastique du débit de synchronisation n'a apporté aucune amélioration.
sauf DSLtest qui continue à dire que la ligne n'existe pas ??
C'est quoi, DSLtest ?
pour pas mourir idiot, mon post cherche donc à connaitre les taux d'erreurs selon la taille du mtu,
Le taux d'erreur par bit est le même quelle que soit la taille du paquet. Le taux d'erreur par paquet est proportionnel à la taille du paquet. En fait c'est un peu plus compliqué que ça, car c'est le taux d'erreur brut avant correction qui est proportionnel à la taille ; le taux d'erreur non corrigeables dépend aussi de l'entrelacement (interleave) qui permet de répartir une salve d'erreurs (causée par un gros paraiste impulsionnel par exemple) sur plusieurs paquets afin de mieux les corriger.
mais peut-être est-ce simplement la 1ere grosse trame, à 1500 octets sui n'arrive pas à passer ?
Ça peut arriver, notamment en PPPoE qui limite à 1492. Il y a quelques problèmes connus de "trou noir de MTU" avec cette encapsulation.
Google passe car il n'emet pas de grosses trames ?
Ce n'est pas difficile à vérifier : capture réseau des communications HTTP avec l'un ou l'autre serveur, regarder les valeurs de MSS échangées à l'établissement de la connexion et les tailles maxi des paquets reçus.
bpdu92 a écrit :
On Sun, 08 Feb 2009 19:53:30 +0100, Pascal Hambourg wrote:
Par curiosité, quelle est donc cette liaison dont le taux d'erreur de
transmission est tel qu'il nécessiterait une réduction du MTU ?
c'est une liaison Orange dans Paris 16eme un peu bizarre :
Une liaison ADSL ? PPPoE ou PPPoA ?
même aprés reduction (par la HotLine Orange) du débit
de 18 à 8 Mbps,il était impossible d'aller sur certains sites,
par ex Boursorama et Yahoo,
alors que d'autres, par ex les pages Google étaient accédés sans pb
aprés réduction de MTU à 1400, au lieu de 1500, tout est redevenu ok,
Problème de MTU a priori, surtout si c'est du tout ou rien. Je ne vois
pas ce qui te fais penser à des erreurs de transmission en ligne,
surtout si la diminution drastique du débit de synchronisation n'a
apporté aucune amélioration.
sauf DSLtest qui continue à dire que la ligne n'existe pas ??
C'est quoi, DSLtest ?
pour pas mourir idiot, mon post cherche donc à connaitre
les taux d'erreurs selon la taille du mtu,
Le taux d'erreur par bit est le même quelle que soit la taille du
paquet. Le taux d'erreur par paquet est proportionnel à la taille du
paquet. En fait c'est un peu plus compliqué que ça, car c'est le taux
d'erreur brut avant correction qui est proportionnel à la taille ; le
taux d'erreur non corrigeables dépend aussi de l'entrelacement
(interleave) qui permet de répartir une salve d'erreurs (causée par un
gros paraiste impulsionnel par exemple) sur plusieurs paquets afin de
mieux les corriger.
mais peut-être est-ce simplement la 1ere grosse trame, à 1500 octets
sui n'arrive pas à passer ?
Ça peut arriver, notamment en PPPoE qui limite à 1492. Il y a quelques
problèmes connus de "trou noir de MTU" avec cette encapsulation.
Google passe car il n'emet pas de grosses trames ?
Ce n'est pas difficile à vérifier : capture réseau des communications
HTTP avec l'un ou l'autre serveur, regarder les valeurs de MSS échangées
à l'établissement de la connexion et les tailles maxi des paquets reçus.
On Sun, 08 Feb 2009 19:53:30 +0100, Pascal Hambourg wrote:
Par curiosité, quelle est donc cette liaison dont le taux d'erreur de transmission est tel qu'il nécessiterait une réduction du MTU ?
c'est une liaison Orange dans Paris 16eme un peu bizarre :
Une liaison ADSL ? PPPoE ou PPPoA ?
même aprés reduction (par la HotLine Orange) du débit de 18 à 8 Mbps,il était impossible d'aller sur certains sites, par ex Boursorama et Yahoo, alors que d'autres, par ex les pages Google étaient accédés sans pb
aprés réduction de MTU à 1400, au lieu de 1500, tout est redevenu ok,
Problème de MTU a priori, surtout si c'est du tout ou rien. Je ne vois pas ce qui te fais penser à des erreurs de transmission en ligne, surtout si la diminution drastique du débit de synchronisation n'a apporté aucune amélioration.
sauf DSLtest qui continue à dire que la ligne n'existe pas ??
C'est quoi, DSLtest ?
pour pas mourir idiot, mon post cherche donc à connaitre les taux d'erreurs selon la taille du mtu,
Le taux d'erreur par bit est le même quelle que soit la taille du paquet. Le taux d'erreur par paquet est proportionnel à la taille du paquet. En fait c'est un peu plus compliqué que ça, car c'est le taux d'erreur brut avant correction qui est proportionnel à la taille ; le taux d'erreur non corrigeables dépend aussi de l'entrelacement (interleave) qui permet de répartir une salve d'erreurs (causée par un gros paraiste impulsionnel par exemple) sur plusieurs paquets afin de mieux les corriger.
mais peut-être est-ce simplement la 1ere grosse trame, à 1500 octets sui n'arrive pas à passer ?
Ça peut arriver, notamment en PPPoE qui limite à 1492. Il y a quelques problèmes connus de "trou noir de MTU" avec cette encapsulation.
Google passe car il n'emet pas de grosses trames ?
Ce n'est pas difficile à vérifier : capture réseau des communications HTTP avec l'un ou l'autre serveur, regarder les valeurs de MSS échangées à l'établissement de la connexion et les tailles maxi des paquets reçus.
