Auteur Sujet: 2Gb/s avec un adapteur USB 3  (Lu 4746 fois)

0 Membres et 1 Invité sur ce sujet

hwti

  • Client Orange Fibre
  • *
  • Messages: 1 587
  • Chambly (60)
2Gb/s avec un adapteur USB 3
« Réponse #24 le: 27 juillet 2020 à 01:32:10 »
La fonction agrégation statique des drivers Intel (pas d'agrégation supportée de base sur les Windows non serveur) semble en partie fonctionner :
 - un curl : 1Gbps (une connexion TCP ne peut donc pas passer par les deux liens)
 - deux curl : la plupart du temps 2Gbps, mais parfois 1Gbps partagé entre les deux sur la même interface (surtout quand je les lance en même temps, et pas avec quelques secondes de décalage)
 - nperf (appli ou browser), speedtest (browser) donnent la plupart du temp 1Gbps, et un peu instable, mais j'ai un test avec une moyenne à 1612Mbps.

Il y a une consommation CPU importante sur un coeur, donc c'est peut-être ça qui limite dans certains cas, mais le comportement est très étrange.

Je ne sais pas si les drivers Intel font quelque chose de particulier : l'outil configure les deux cartes avec la même MAC, il n'y a bien qu'une seule IP.
Ce qui est sûr, c'est que je peux avoir deux curl qui font l'envoi sur une connexion, et la réception sur une autre : la LB5 ne semble donc pas répondre sur l'interface ayant initié la connexion (sauf si le driver Intel a décidé de changer l'interface d'envoi en cours de connexion, ce qui serait bizarre).

Peut-être qu'il y a quelque chose autour des réponse ARP (ou des envois spontanés), soit aléatoire, soit piloté par le driver Intel.
Par exemple, la Livebox pourrait utiliser la dernière réponse ARP et donc voir régulièrement le PC "changer de port". L'agrégation fonctionnerait alors grâce au fait que les connexions TCP seraient routées vers le "port courant" au moment où elles ont été établies, même s'il change ensuite.

hwti

  • Client Orange Fibre
  • *
  • Messages: 1 587
  • Chambly (60)
2Gb/s avec un adapteur USB 3
« Réponse #25 le: 28 juillet 2020 à 02:49:04 »
Les drivers Intel font bien quelque chose, le paramètre "vitesse d'actualisation de l'équilibre de la charge" a un effet :
 - par défaut il vaut 10
 - si je le met à 0 "répartition statique", tout passe par la première interface
 - si je le met à 1, la répartition fonctionne mieux

Ca veut dire que la Livebox ne décide pas elle-même sur quel lien les différentes connexions sont envoyées, elle est influencée par le PC (ce qui ressemble plus à Adaptive Load Balancing normalement, pas Static Link Agregation).

Il y a encore des tests qui plafonnent à 1Gbps, c'est aléatoire.
De même, l'upload a un peu de mal, et parfois s'effondre quand les paquets semblent répartis sur les deux interfaces.

Un cas où l'upload d'est fait sur une interface :


Un cas où l'upload a été réparti entre les interfaces (variation visible sur la courbe de débit) :



iMot3k

  • Client Orange Fibre
  • *
  • Messages: 21
2Gb/s avec un adapteur USB 3
« Réponse #26 le: 07 août 2020 à 23:53:16 »
Thread très intéressant, dommage que je n'ai pas l'air d'être le bienvenu  :-\

iMot3k

  • Client Orange Fibre
  • *
  • Messages: 21
2Gb/s avec un adapteur USB 3
« Réponse #27 le: 08 août 2020 à 00:21:07 »
Les drivers Intel font bien quelque chose, le paramètre "vitesse d'actualisation de l'équilibre de la charge" a un effet :
 - par défaut il vaut 10
 - si je le met à 0 "répartition statique", tout passe par la première interface
 - si je le met à 1, la répartition fonctionne mieux

Ca veut dire que la Livebox ne décide pas elle-même sur quel lien les différentes connexions sont envoyées, elle est influencée par le PC (ce qui ressemble plus à Adaptive Load Balancing normalement, pas Static Link Agregation).

Il y a encore des tests qui plafonnent à 1Gbps, c'est aléatoire.
De même, l'upload a un peu de mal, et parfois s'effondre quand les paquets semblent répartis sur les deux interfaces.

Un cas où l'upload d'est fait sur une interface :


Un cas où l'upload a été réparti entre les interfaces (variation visible sur la courbe de débit) :


J'ai essayé de changer ce réglage à 1 comme tu dit, mais l'upload est toujours un peu dégueu... Comment tu fais pour "envoyer l'upload que sur un seul adaptateur" de manière sûre ?

hwti

  • Client Orange Fibre
  • *
  • Messages: 1 587
  • Chambly (60)
2Gb/s avec un adapteur USB 3
« Réponse #28 le: 08 août 2020 à 06:04:56 »
J'ai essayé de changer ce réglage à 1 comme tu dit, mais l'upload est toujours un peu dégueu... Comment tu fais pour "envoyer l'upload que sur un seul adaptateur" de manière sûre ?
Le réglage à 1, c'est pour le download.
Pour l'upload, je n'ai fait que constater deux comportements différents, qui semblent aléatoires.
Il n'est pas possible d'activer npcap sur les interfaces individuelles, donc Wireshark ne voit que l'agrégation : impossible de s'en servir pour voir ce que le driver Intel fait vraiment.

Je vais essayer d'expérimenter avec Linux, mais il n'y a peut-être pas de mode équivalent, ni de moyen de limiter l'upload à une seule interface (si c'est réellement le problème).

iMot3k

  • Client Orange Fibre
  • *
  • Messages: 21
2Gb/s avec un adapteur USB 3
« Réponse #29 le: 08 août 2020 à 10:38:46 »
Le réglage à 1, c'est pour le download.
Pour l'upload, je n'ai fait que constater deux comportements différents, qui semblent aléatoires.
Il n'est pas possible d'activer npcap sur les interfaces individuelles, donc Wireshark ne voit que l'agrégation : impossible de s'en servir pour voir ce que le driver Intel fait vraiment.

Je vais essayer d'expérimenter avec Linux, mais il n'y a peut-être pas de mode équivalent, ni de moyen de limiter l'upload à une seule interface (si c'est réellement le problème).

Techniquement si l'upload est stable quand on utilise qu'une seule interface je suppose qu'en uploadant sur une seule ça devrait fonctionner...

hwti

  • Client Orange Fibre
  • *
  • Messages: 1 587
  • Chambly (60)
2Gb/s avec un adapteur USB 3
« Réponse #30 le: 08 août 2020 à 21:42:05 »
Techniquement si l'upload est stable quand on utilise qu'une seule interface je suppose qu'en uploadant sur une seule ça devrait fonctionner...
Ce n'est pas forcément possible (même en écrivant un driver dédié), parce qu'au moment de l'établissement d'une connexion TCP sortante (par exemple), l'OS ne sait pas quel sera son usage (majoritairement download, upload, ou les deux).

Je vois deux hypothèses qui expliqueraient le fonctionnement en download :
 - les ARP changent le port "actif", et c'est celui au moment de l'établissement de la "connexion" qui récupère le flux ensuite
 - le port ayant établi la "connexion" reçoit les paquets associés

Si c'est le premier cas, alors il est effectivement théoriquement possible d'envoyer toutes les trames sur le même port, tout en répondant aux ARP (ou en envoyant des "ARP gratuits") alternativement sur les deux ports (au en fonction de leur charge en réception).
Si c'est le second cas, alors il faut que les TCP SYN des connexions "de download" soient répartis sur les deux ports.

Adefre

  • Expert Orange
  • Client Orange Fibre
  • *
  • Messages: 451
  • FTTH 2 Gb/s Paris 08
    • Blog Fibre
2Gb/s avec un adapteur USB 3
« Réponse #31 le: 11 août 2020 à 19:51:36 »
Thread très intéressant, dommage que je n'ai pas l'air d'être le bienvenu  :-\

Mais si t'inquiète :) ils sont un peu taquins

hwti

  • Client Orange Fibre
  • *
  • Messages: 1 587
  • Chambly (60)
2Gb/s avec un adapteur USB 3
« Réponse #32 le: 14 août 2020 à 08:48:29 »
J'ai pu capturer les paquets sur les deux interfaces sous Windows a l'aide de pktmon.
Avec deux curl lancés avec 2s d'écart, je ne vois aucun ARP entre les deux, les SYN effectués sur les deux interfaces, et le SYN+ACK qui revient sur l'interface ayant effectué le SYN.

Mais sous Linux, avec le module bond en mode=balance-xor xmit_hash_policy=layer3+4, ça ne fonctionne pas bien du tout :
 - avec deux connexions établies en même temps, les SYN partent sur des interfaces différentes, mais les SYN+ACK peuvent être reçus sur une seule interface, ou en "croisé"
 - la plupart du temps, on reste limité à 1Gbps (réception sur une interface), et parfois on a presque 2Gbps
 - pendant les transferts, il y a des pertes de paquets sur le LAN si je fais un ping depuis une autre machine (le switch ne doit pas aimer)
Il n'y a pas de lien entre l'interface sur laquelle le SYN+ACK a été reçu, et celle qui va servir par la suite (on peut avoir la réponse initiale sur une même interface et 2Gbps par la suite, ou l'inverse).

La Livebox ne répond donc pas simplement sur le port ayant initié la connexion, c'est probablement plus compliqué.
Je ne sais pas pourquoi l’agrégation des drivers Intel sous Windows semble mieux s'en sortir, peut-être qu'un "basculement" plus lent entre les deux interfaces pose moins de problèmes.
« Modifié: 14 août 2020 à 09:25:33 par hwti »