je reviens vers vous concernant le bonding dont on avait parlé dans un
autre message ( Re: Aggrégation débit - IP fallback du 19/12/2011 à 21h41 ).
Ce bonding est maintenant en exploitation avec les paramètres suivants :
- liens openvpn tap,
- bonding mode=0, monitoring par ARP ;
- bonding de chaque côté du VPN ;
- liens 1 et 2 : 512 kb/s ;
- lien 3 : 1 M/s.
J'aurais deux questions :
1. le mode 0 est du round robing, mais du vrai. Les débits sont quasi
les mêmes sur chaque liens alors que un lien pourrait permettre d'aller
deux fois plus vite. Pensez vous que je puisse passer en mode 802.3ad
sachant que chaque côté est une machine linux avec le driver bonding ?
Sinon comment pourrais-je exploiter complètement le lien le plus rapide ?
2. il y a des cycles dans le débit : ça accélère puis ralenti puis
accélère puis ralenti, ... alors que si on prends les connexions
individuellement, le débit est relativement stable. Une idée ?
Merci,
Laurent
--
Remplacez yahou par yahoo et com par fr pour me répondre en direct
je reviens vers vous concernant le bonding dont on avait parlé dans un autre message ( Re: Aggrégation débit - IP fallback du 19/12/2011 à 21h41 ).
Ce bonding est maintenant en exploitation avec les paramètres suivants : - liens openvpn tap, - bonding mode=0, monitoring par ARP ; - bonding de chaque côté du VPN ; - liens 1 et 2 : 512 kb/s ; - lien 3 : 1 M/s.
J'aurais deux questions : 1. le mode 0 est du round robing, mais du vrai. Les débits sont quasi les mêmes sur chaque liens alors que un lien pourrait permettre d'aller deux fois plus vite. Pensez vous que je puisse passer en mode 802.3ad sachant que chaque côté est une machine linux avec le driver bonding ?
Dans Documentation/bonding.txt on peut lire qu'un des prérequis est la prise en charge d'ethtool par le pilote des interfaces pour récupérer la vitesse et le duplex. Je doute que ce soit possible dans ton cas, le débit étant fixés par les liens xDSL.
Sinon comment pourrais-je exploiter complètement le lien le plus rapide ?
J'avais suggéré d'agréger les deux liens à 512 Mbit/s, puis d'agréger le bonding résultant avec le lien à 1 Mbit/s dans un second bonding.
2. il y a des cycles dans le débit : ça accélère puis ralenti puis accélère puis ralenti, ... alors que si on prends les connexions individuellement, le débit est relativement stable. Une idée ?
Pas vraiment, mais ça pourrait être un effet de la différence de capacité des liens.
Salut,
Essomba a écrit :
Bonjour à tous,
je reviens vers vous concernant le bonding dont on avait parlé dans un
autre message ( Re: Aggrégation débit - IP fallback du 19/12/2011 à 21h41 ).
Ce bonding est maintenant en exploitation avec les paramètres suivants :
- liens openvpn tap,
- bonding mode=0, monitoring par ARP ;
- bonding de chaque côté du VPN ;
- liens 1 et 2 : 512 kb/s ;
- lien 3 : 1 M/s.
J'aurais deux questions :
1. le mode 0 est du round robing, mais du vrai. Les débits sont quasi
les mêmes sur chaque liens alors que un lien pourrait permettre d'aller
deux fois plus vite. Pensez vous que je puisse passer en mode 802.3ad
sachant que chaque côté est une machine linux avec le driver bonding ?
Dans Documentation/bonding.txt on peut lire qu'un des prérequis est la
prise en charge d'ethtool par le pilote des interfaces pour récupérer la
vitesse et le duplex. Je doute que ce soit possible dans ton cas, le
débit étant fixés par les liens xDSL.
Sinon comment pourrais-je exploiter complètement le lien le plus rapide ?
J'avais suggéré d'agréger les deux liens à 512 Mbit/s, puis d'agréger le
bonding résultant avec le lien à 1 Mbit/s dans un second bonding.
2. il y a des cycles dans le débit : ça accélère puis ralenti puis
accélère puis ralenti, ... alors que si on prends les connexions
individuellement, le débit est relativement stable. Une idée ?
Pas vraiment, mais ça pourrait être un effet de la différence de
capacité des liens.
je reviens vers vous concernant le bonding dont on avait parlé dans un autre message ( Re: Aggrégation débit - IP fallback du 19/12/2011 à 21h41 ).
Ce bonding est maintenant en exploitation avec les paramètres suivants : - liens openvpn tap, - bonding mode=0, monitoring par ARP ; - bonding de chaque côté du VPN ; - liens 1 et 2 : 512 kb/s ; - lien 3 : 1 M/s.
J'aurais deux questions : 1. le mode 0 est du round robing, mais du vrai. Les débits sont quasi les mêmes sur chaque liens alors que un lien pourrait permettre d'aller deux fois plus vite. Pensez vous que je puisse passer en mode 802.3ad sachant que chaque côté est une machine linux avec le driver bonding ?
Dans Documentation/bonding.txt on peut lire qu'un des prérequis est la prise en charge d'ethtool par le pilote des interfaces pour récupérer la vitesse et le duplex. Je doute que ce soit possible dans ton cas, le débit étant fixés par les liens xDSL.
Sinon comment pourrais-je exploiter complètement le lien le plus rapide ?
J'avais suggéré d'agréger les deux liens à 512 Mbit/s, puis d'agréger le bonding résultant avec le lien à 1 Mbit/s dans un second bonding.
2. il y a des cycles dans le débit : ça accélère puis ralenti puis accélère puis ralenti, ... alors que si on prends les connexions individuellement, le débit est relativement stable. Une idée ?
Pas vraiment, mais ça pourrait être un effet de la différence de capacité des liens.
essomba84
On 24/02/2012 20:41, Pascal Hambourg wrote:
J'avais suggéré d'agréger les deux liens à 512 Mbit/s, puis d'agréger le bonding résultant avec le lien à 1 Mbit/s dans un second bonding.
ben oui, c'est une bonne idée sauf que ifenslave refuse une interface slave de type bond... Ou alors je m'y prends mal...
On 24/02/2012 20:41, Pascal Hambourg wrote:
J'avais suggéré d'agréger les deux liens à 512 Mbit/s, puis d'agréger le
bonding résultant avec le lien à 1 Mbit/s dans un second bonding.
ben oui, c'est une bonne idée sauf que ifenslave refuse une interface
slave de type bond... Ou alors je m'y prends mal...
Sinon j'ai eu une autre idée : je crée 2 VPN sur l'interface deux fois plus rapide et j'agrège 4 liens. J'arrive donc à avoir un débit qui est la somme des 3 débits de FAI mais malhreusement ça reste très très instable... Une idée de pourquoi ?
Merci,
Laurent
On 24/02/2012 22:37, Pascal Hambourg wrote:
essomba84 a écrit :
On 24/02/2012 20:41, Pascal Hambourg wrote:
J'avais suggéré d'agréger les deux liens à 512 Mbit/s, puis d'agréger le
bonding résultant avec le lien à 1 Mbit/s dans un second bonding.
ben oui, c'est une bonne idée sauf que ifenslave refuse une interface
slave de type bond... Ou alors je m'y prends mal...
Que se passe-t-il ?
Je viens de tester sur une Debian Squeeze avec trois interfaces dummy,
ça a l'air de marcher.
Sinon j'ai eu une autre idée : je crée 2 VPN sur l'interface deux fois
plus rapide et j'agrège 4 liens. J'arrive donc à avoir un débit qui est
la somme des 3 débits de FAI mais malhreusement ça reste très très
instable... Une idée de pourquoi ?
Sinon j'ai eu une autre idée : je crée 2 VPN sur l'interface deux fois plus rapide et j'agrège 4 liens. J'arrive donc à avoir un débit qui est la somme des 3 débits de FAI mais malhreusement ça reste très très instable... Une idée de pourquoi ?
Merci,
Laurent
Pascal Hambourg
essomba84 a écrit :
On 24/02/2012 22:37, Pascal Hambourg wrote:
essomba84 a écrit :
ben oui, c'est une bonne idée sauf que ifenslave refuse une interface slave de type bond... Ou alors je m'y prends mal...
Que se passe-t-il ? Je viens de tester sur une Debian Squeeze avec trois interfaces dummy, ça a l'air de marcher.
Sinon j'ai eu une autre idée : je crée 2 VPN sur l'interface deux fois plus rapide et j'agrège 4 liens.
Bien vu.
J'arrive donc à avoir un débit qui est la somme des 3 débits de FAI mais malhreusement ça reste très très instable... Une idée de pourquoi ?
Non, à part que ça doit être lié au comportement de TCP. Quelle est la forme, la périodicité et l'amplitude de la variation de débit ? Y a-t-il une grosse différence de latence entre les liaisons Wimax et ADSL ? Dans ce cas, il y a peut-être un effet lié à la réception dans le désordre, et augmenter la valeur de tcp_reordering pourrait aider.
essomba84 a écrit :
On 24/02/2012 22:37, Pascal Hambourg wrote:
essomba84 a écrit :
ben oui, c'est une bonne idée sauf que ifenslave refuse une interface
slave de type bond... Ou alors je m'y prends mal...
Que se passe-t-il ?
Je viens de tester sur une Debian Squeeze avec trois interfaces dummy,
ça a l'air de marcher.
Sinon j'ai eu une autre idée : je crée 2 VPN sur l'interface deux fois
plus rapide et j'agrège 4 liens.
Bien vu.
J'arrive donc à avoir un débit qui est
la somme des 3 débits de FAI mais malhreusement ça reste très très
instable... Une idée de pourquoi ?
Non, à part que ça doit être lié au comportement de TCP. Quelle est la
forme, la périodicité et l'amplitude de la variation de débit ?
Y a-t-il une grosse différence de latence entre les liaisons Wimax et
ADSL ? Dans ce cas, il y a peut-être un effet lié à la réception dans le
désordre, et augmenter la valeur de tcp_reordering pourrait aider.
Sinon j'ai eu une autre idée : je crée 2 VPN sur l'interface deux fois plus rapide et j'agrège 4 liens.
Bien vu.
J'arrive donc à avoir un débit qui est la somme des 3 débits de FAI mais malhreusement ça reste très très instable... Une idée de pourquoi ?
Non, à part que ça doit être lié au comportement de TCP. Quelle est la forme, la périodicité et l'amplitude de la variation de débit ? Y a-t-il une grosse différence de latence entre les liaisons Wimax et ADSL ? Dans ce cas, il y a peut-être un effet lié à la réception dans le désordre, et augmenter la valeur de tcp_reordering pourrait aider.
essomba84
On 25/02/2012 01:29, Pascal Hambourg wrote:
Quelle distribution/version/noyau ?
debian sid, noyau 3.2.0-1-amd64
Sinon j'ai eu une autre idée : je crée 2 VPN sur l'interface deux fois plus rapide et j'agrège 4 liens.
Bien vu.
J'arrive donc à avoir un débit qui est la somme des 3 débits de FAI mais malhreusement ça reste très très instable... Une idée de pourquoi ?
Non, à part que ça doit être lié au comportement de TCP. Quelle est la forme, la périodicité et l'amplitude de la variation de débit ?
je n'ai pas de graphique. Mais les variations vont de 170ko/s à 35 en l'espace de 3s puis ça met une dizaine de seconde à remonter vers 170. Et en permanence sur un fichier de 5Mo.
Y a-t-il une grosse différence de latence entre les liaisons Wimax et ADSL ? Dans ce cas, il y a peut-être un effet lié à la réception dans le désordre, et augmenter la valeur de tcp_reordering pourrait aider.
en gros sur la ligne adsl je ping ma passerelle en 200ms et en wimax en 260ms. Il est clair que le problème viens de l'agrégation avec la ligne ADSL. En fait j'ai 109ko/s stable en agrégeant les deux wimax. Dès que je mets la ligne ADSL, ça commence à faire n'importe quoi alors que seule, elle est à 119ko/s stable...
Je dois changer la valeur de tcp_reordering à quel niveau ? la machine locale ou la machine distante ? les deux ? sur quelle interface ? celles des VPN ? celles de sorties ? celle du bond ?
Merci,
Laurent
On 25/02/2012 01:29, Pascal Hambourg wrote:
Quelle distribution/version/noyau ?
debian sid, noyau 3.2.0-1-amd64
Sinon j'ai eu une autre idée : je crée 2 VPN sur l'interface deux fois
plus rapide et j'agrège 4 liens.
Bien vu.
J'arrive donc à avoir un débit qui est
la somme des 3 débits de FAI mais malhreusement ça reste très très
instable... Une idée de pourquoi ?
Non, à part que ça doit être lié au comportement de TCP. Quelle est la
forme, la périodicité et l'amplitude de la variation de débit ?
je n'ai pas de graphique. Mais les variations vont de 170ko/s à 35 en
l'espace de 3s puis ça met une dizaine de seconde à remonter vers 170.
Et en permanence sur un fichier de 5Mo.
Y a-t-il une grosse différence de latence entre les liaisons Wimax et
ADSL ? Dans ce cas, il y a peut-être un effet lié à la réception dans le
désordre, et augmenter la valeur de tcp_reordering pourrait aider.
en gros sur la ligne adsl je ping ma passerelle en 200ms et en wimax en
260ms. Il est clair que le problème viens de l'agrégation avec la ligne
ADSL. En fait j'ai 109ko/s stable en agrégeant les deux wimax. Dès que
je mets la ligne ADSL, ça commence à faire n'importe quoi alors que
seule, elle est à 119ko/s stable...
Je dois changer la valeur de tcp_reordering à quel niveau ? la machine
locale ou la machine distante ? les deux ? sur quelle interface ? celles
des VPN ? celles de sorties ? celle du bond ?
Sinon j'ai eu une autre idée : je crée 2 VPN sur l'interface deux fois plus rapide et j'agrège 4 liens.
Bien vu.
J'arrive donc à avoir un débit qui est la somme des 3 débits de FAI mais malhreusement ça reste très très instable... Une idée de pourquoi ?
Non, à part que ça doit être lié au comportement de TCP. Quelle est la forme, la périodicité et l'amplitude de la variation de débit ?
je n'ai pas de graphique. Mais les variations vont de 170ko/s à 35 en l'espace de 3s puis ça met une dizaine de seconde à remonter vers 170. Et en permanence sur un fichier de 5Mo.
Y a-t-il une grosse différence de latence entre les liaisons Wimax et ADSL ? Dans ce cas, il y a peut-être un effet lié à la réception dans le désordre, et augmenter la valeur de tcp_reordering pourrait aider.
en gros sur la ligne adsl je ping ma passerelle en 200ms et en wimax en 260ms. Il est clair que le problème viens de l'agrégation avec la ligne ADSL. En fait j'ai 109ko/s stable en agrégeant les deux wimax. Dès que je mets la ligne ADSL, ça commence à faire n'importe quoi alors que seule, elle est à 119ko/s stable...
Je dois changer la valeur de tcp_reordering à quel niveau ? la machine locale ou la machine distante ? les deux ? sur quelle interface ? celles des VPN ? celles de sorties ? celle du bond ?
Merci,
Laurent
Pascal Hambourg
essomba84 a écrit :
On 25/02/2012 01:29, Pascal Hambourg wrote:
Quelle distribution/version/noyau ?
debian sid, noyau 3.2.0-1-amd64
J'ai pas sous la main, mais j'essaierai de regarder si un changement peut expliquer ça.
>> J'arrive donc à avoir un débit qui est >> la somme des 3 débits de FAI mais malhreusement ça reste très très >> instable... Une idée de pourquoi ? > > Non, à part que ça doit être lié au comportement de TCP. Quelle est la > forme, la périodicité et l'amplitude de la variation de débit ?
je n'ai pas de graphique. Mais les variations vont de 170ko/s à 35 en l'espace de 3s puis ça met une dizaine de seconde à remonter vers 170. Et en permanence sur un fichier de 5Mo.
En dents de scie, donc. Comme lors d'une perte de paquets importante, TCP réduit brusquement le débit puis augmente progressivement.
en gros sur la ligne adsl je ping ma passerelle en 200ms et en wimax en 260ms. Il est clair que le problème viens de l'agrégation avec la ligne ADSL. En fait j'ai 109ko/s stable en agrégeant les deux wimax. Dès que je mets la ligne ADSL, ça commence à faire n'importe quoi alors que seule, elle est à 119ko/s stable...
Je dois changer la valeur de tcp_reordering à quel niveau ? la machine locale ou la machine distante ? les deux ? sur quelle interface ? celles des VPN ? celles de sorties ? celle du bond ?
Sur la machine finale qui reçoit le fichier puisque c'est elle qui fait la remise dans l'ordre des segments TCP. Ce paramètre n'est pas lié à une interface particulière (sysctl net.ipv4.tcp_reordering).
essomba84 a écrit :
On 25/02/2012 01:29, Pascal Hambourg wrote:
Quelle distribution/version/noyau ?
debian sid, noyau 3.2.0-1-amd64
J'ai pas sous la main, mais j'essaierai de regarder si un changement
peut expliquer ça.
>> J'arrive donc à avoir un débit qui est
>> la somme des 3 débits de FAI mais malhreusement ça reste très très
>> instable... Une idée de pourquoi ?
>
> Non, à part que ça doit être lié au comportement de TCP. Quelle est la
> forme, la périodicité et l'amplitude de la variation de débit ?
je n'ai pas de graphique. Mais les variations vont de 170ko/s à 35 en
l'espace de 3s puis ça met une dizaine de seconde à remonter vers 170.
Et en permanence sur un fichier de 5Mo.
En dents de scie, donc. Comme lors d'une perte de paquets importante,
TCP réduit brusquement le débit puis augmente progressivement.
en gros sur la ligne adsl je ping ma passerelle en 200ms et en wimax en
260ms. Il est clair que le problème viens de l'agrégation avec la ligne
ADSL. En fait j'ai 109ko/s stable en agrégeant les deux wimax. Dès que
je mets la ligne ADSL, ça commence à faire n'importe quoi alors que
seule, elle est à 119ko/s stable...
Je dois changer la valeur de tcp_reordering à quel niveau ? la machine
locale ou la machine distante ? les deux ? sur quelle interface ? celles
des VPN ? celles de sorties ? celle du bond ?
Sur la machine finale qui reçoit le fichier puisque c'est elle qui fait
la remise dans l'ordre des segments TCP. Ce paramètre n'est pas lié à
une interface particulière (sysctl net.ipv4.tcp_reordering).
J'ai pas sous la main, mais j'essaierai de regarder si un changement peut expliquer ça.
>> J'arrive donc à avoir un débit qui est >> la somme des 3 débits de FAI mais malhreusement ça reste très très >> instable... Une idée de pourquoi ? > > Non, à part que ça doit être lié au comportement de TCP. Quelle est la > forme, la périodicité et l'amplitude de la variation de débit ?
je n'ai pas de graphique. Mais les variations vont de 170ko/s à 35 en l'espace de 3s puis ça met une dizaine de seconde à remonter vers 170. Et en permanence sur un fichier de 5Mo.
En dents de scie, donc. Comme lors d'une perte de paquets importante, TCP réduit brusquement le débit puis augmente progressivement.
en gros sur la ligne adsl je ping ma passerelle en 200ms et en wimax en 260ms. Il est clair que le problème viens de l'agrégation avec la ligne ADSL. En fait j'ai 109ko/s stable en agrégeant les deux wimax. Dès que je mets la ligne ADSL, ça commence à faire n'importe quoi alors que seule, elle est à 119ko/s stable...
Je dois changer la valeur de tcp_reordering à quel niveau ? la machine locale ou la machine distante ? les deux ? sur quelle interface ? celles des VPN ? celles de sorties ? celle du bond ?
Sur la machine finale qui reçoit le fichier puisque c'est elle qui fait la remise dans l'ordre des segments TCP. Ce paramètre n'est pas lié à une interface particulière (sysctl net.ipv4.tcp_reordering).
Tonton Th
On 02/24/2012 08:41 PM, Pascal Hambourg wrote:
- liens 1 et 2 : 512 kb/s ; - lien 3 : 1 M/s.
Sinon comment pourrais-je exploiter complètement le lien le plus rapide ?
J'avais suggéré d'agréger les deux liens à 512 Mbit/s, puis d'agréger le bonding résultant avec le lien à 1 Mbit/s dans un second bonding.
Question idiote : en mettant deux tunnels dans le lien rapide, ça ne pourrait pas assurer aussi le bon remplissage, puisque les quatres seraient identiques ?
--
Nous vivons dans un monde étrange/ http://foo.bar.quux.over-blog.com/
On 02/24/2012 08:41 PM, Pascal Hambourg wrote:
- liens 1 et 2 : 512 kb/s ;
- lien 3 : 1 M/s.
Sinon comment pourrais-je exploiter complètement le lien le plus rapide ?
J'avais suggéré d'agréger les deux liens à 512 Mbit/s, puis d'agréger le
bonding résultant avec le lien à 1 Mbit/s dans un second bonding.
Question idiote : en mettant deux tunnels dans le lien rapide,
ça ne pourrait pas assurer aussi le bon remplissage, puisque
les quatres seraient identiques ?
--
Nous vivons dans un monde étrange/
http://foo.bar.quux.over-blog.com/
Sinon comment pourrais-je exploiter complètement le lien le plus rapide ?
J'avais suggéré d'agréger les deux liens à 512 Mbit/s, puis d'agréger le bonding résultant avec le lien à 1 Mbit/s dans un second bonding.
Question idiote : en mettant deux tunnels dans le lien rapide, ça ne pourrait pas assurer aussi le bon remplissage, puisque les quatres seraient identiques ?
--
Nous vivons dans un monde étrange/ http://foo.bar.quux.over-blog.com/
essomba84
On 25/02/2012 12:36, Tonton Th wrote:
On 02/24/2012 08:41 PM, Pascal Hambourg wrote:
- liens 1 et 2 : 512 kb/s ; - lien 3 : 1 M/s.
Sinon comment pourrais-je exploiter complètement le lien le plus rapide ?
J'avais suggéré d'agréger les deux liens à 512 Mbit/s, puis d'agréger le bonding résultant avec le lien à 1 Mbit/s dans un second bonding.
Question idiote : en mettant deux tunnels dans le lien rapide, ça ne pourrait pas assurer aussi le bon remplissage, puisque les quatres seraient identiques ?
bonjour,
je l'ai déjà fait (voire message ci-dessus). Le problème que je remarque est que lorsqu'on agrège deux liens de qualité différentes (ici avec des temps d'accès différents), le bonding ne fonctionne pas bien...
L
On 25/02/2012 12:36, Tonton Th wrote:
On 02/24/2012 08:41 PM, Pascal Hambourg wrote:
- liens 1 et 2 : 512 kb/s ;
- lien 3 : 1 M/s.
Sinon comment pourrais-je exploiter complètement le lien le plus
rapide ?
J'avais suggéré d'agréger les deux liens à 512 Mbit/s, puis d'agréger le
bonding résultant avec le lien à 1 Mbit/s dans un second bonding.
Question idiote : en mettant deux tunnels dans le lien rapide,
ça ne pourrait pas assurer aussi le bon remplissage, puisque
les quatres seraient identiques ?
bonjour,
je l'ai déjà fait (voire message ci-dessus). Le problème que je remarque
est que lorsqu'on agrège deux liens de qualité différentes (ici avec des
temps d'accès différents), le bonding ne fonctionne pas bien...
Sinon comment pourrais-je exploiter complètement le lien le plus rapide ?
J'avais suggéré d'agréger les deux liens à 512 Mbit/s, puis d'agréger le bonding résultant avec le lien à 1 Mbit/s dans un second bonding.
Question idiote : en mettant deux tunnels dans le lien rapide, ça ne pourrait pas assurer aussi le bon remplissage, puisque les quatres seraient identiques ?
bonjour,
je l'ai déjà fait (voire message ci-dessus). Le problème que je remarque est que lorsqu'on agrège deux liens de qualité différentes (ici avec des temps d'accès différents), le bonding ne fonctionne pas bien...
L
essomba84
On 25/02/2012 11:04, Pascal Hambourg wrote:
essomba84 a écrit :
On 25/02/2012 01:29, Pascal Hambourg wrote:
Quelle distribution/version/noyau ?
debian sid, noyau 3.2.0-1-amd64
J'ai pas sous la main, mais j'essaierai de regarder si un changement peut expliquer ça.
>> J'arrive donc à avoir un débit qui est >> la somme des 3 débits de FAI mais malhreusement ça reste très très >> instable... Une idée de pourquoi ? > > Non, à part que ça doit être lié au comportement de TCP. Quelle est la > forme, la périodicité et l'amplitude de la variation de débit ?
je n'ai pas de graphique. Mais les variations vont de 170ko/s à 35 en l'espace de 3s puis ça met une dizaine de seconde à remonter vers 170. Et en permanence sur un fichier de 5Mo.
En dents de scie, donc. Comme lors d'une perte de paquets importante, TCP réduit brusquement le débit puis augmente progressivement.
y a des moyens de voir ce qui se passe ? ou les paquets se perdent ? pourquoi ? combien ?
Merci,
L
On 25/02/2012 11:04, Pascal Hambourg wrote:
essomba84 a écrit :
On 25/02/2012 01:29, Pascal Hambourg wrote:
Quelle distribution/version/noyau ?
debian sid, noyau 3.2.0-1-amd64
J'ai pas sous la main, mais j'essaierai de regarder si un changement
peut expliquer ça.
>> J'arrive donc à avoir un débit qui est
>> la somme des 3 débits de FAI mais malhreusement ça reste très très
>> instable... Une idée de pourquoi ?
>
> Non, à part que ça doit être lié au comportement de TCP. Quelle est la
> forme, la périodicité et l'amplitude de la variation de débit ?
je n'ai pas de graphique. Mais les variations vont de 170ko/s à 35 en
l'espace de 3s puis ça met une dizaine de seconde à remonter vers 170.
Et en permanence sur un fichier de 5Mo.
En dents de scie, donc. Comme lors d'une perte de paquets importante,
TCP réduit brusquement le débit puis augmente progressivement.
y a des moyens de voir ce qui se passe ? ou les paquets se perdent ?
pourquoi ? combien ?
J'ai pas sous la main, mais j'essaierai de regarder si un changement peut expliquer ça.
>> J'arrive donc à avoir un débit qui est >> la somme des 3 débits de FAI mais malhreusement ça reste très très >> instable... Une idée de pourquoi ? > > Non, à part que ça doit être lié au comportement de TCP. Quelle est la > forme, la périodicité et l'amplitude de la variation de débit ?
je n'ai pas de graphique. Mais les variations vont de 170ko/s à 35 en l'espace de 3s puis ça met une dizaine de seconde à remonter vers 170. Et en permanence sur un fichier de 5Mo.
En dents de scie, donc. Comme lors d'une perte de paquets importante, TCP réduit brusquement le débit puis augmente progressivement.
y a des moyens de voir ce qui se passe ? ou les paquets se perdent ? pourquoi ? combien ?
