Auteur Sujet: FTTH 10G Free: Mesure de débit automatisé avec iPerf3 en IPv4 vs IPv6  (Lu 74764 fois)

0 Membres et 1 Invité sur ce sujet

Breizh29

  • Abonné Free fibre
  • *
  • Messages: 408
  • Ergué-Gabéric (29)
FTTH 10G Free: Mesure de débit automatisé avec iPerf3 en IPv4 vs IPv6
« Réponse #180 le: 27 janvier 2020 à 09:16:08 »
Mise à jour de ce matin 9h






vivien

  • Administrateur
  • *
  • Messages: 47 080
    • Twitter LaFibre.info
FTTH 10G Free: Mesure de débit automatisé avec iPerf3 en IPv4 vs IPv6
« Réponse #181 le: 27 janvier 2020 à 16:13:27 »
J'ai ça actuellement :
# Increase TCP buffers
net.ipv4.tcp_rmem=4096 131072 16777216
net.ipv4.tcp_wmem=4096 87380 16777216
net.core.rmem_max=851968
net.core.wmem_max=851968

Il me semble que net.core.[rw]mem_max prend le pas sur la valeur max de net.ipv4.tcp_[rw]mem (contrairement à la valeur par défaut).
Si c'est vrai, ça voudrait dire que sur ton serveur, les buffers TCP ne peuvent pas dépasser 832Ko.

https://www.ibm.com/support/knowledgecenter/linuxonibm/liaag/wkvm/wkvm_c_tune_tcpip.htm

net.ipv4.tcp_wmem

Similar to the net.ipv4.tcp_rmem this parameter consists of 3 values, a minimum, default, and maximum.

The minimum represents the smallest receive buffer size a newly created socket is entitled to as part of its creation. The minimum value defaults to 1 page or 4096 bytes.

The default value represents the initial size of a TCP sockets receive buffer. This value supersedes net.core.rmem_default used by other protocols. It is typically set lower than net.core.wmem_default. The default value for this setting is 16K bytes.

The maximum represents the largest receive buffer size for auto-tuned send buffers for TCP sockets. This value does not override net.core.rmem_max. The default value for this setting is somewhere between 64K bytes and 4M bytes based on the amount of memory available in the system.

The recommendation is to use the maximum value of 16M bytes or higher (kernel level dependent) especially for 10 Gigabit adapters.


Autre explication : https://cloud.google.com/solutions/tcp-optimization-for-network-performance-in-gcp-and-hybrid?hl=fr

La taille de la fenêtre TCP est affectée par les 4 paramètres suivants :
•   net.core.rmem_max
•   net.core.wmem_max
•   net.ipv4.tcp_rmem
•   net.ipv4.tcp_wmem

Les deux premiers paramètres configurables affectent la taille maximale de fenêtre TCP pour les applications qui tentent de contrôler directement la taille de la fenêtre TCP, en limitant la requête des applications à ces valeurs seulement. Les deux autres paramètres configurables affectent la taille de fenêtre TCP pour les applications qui laissent la fonction de réglage automatique de Linux se charger de cette tâche.

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
FTTH 10G Free: Mesure de débit automatisé avec iPerf3 en IPv4 vs IPv6
« Réponse #182 le: 27 janvier 2020 à 21:37:04 »
y'a des bizarreries avec IPerf3 et Windows:

serveur: Linux IPerf3 3.7 avec
net.core.rmem_default = 212992
net.core.rmem_max = 212992
net.core.wmem_default = 212992
net.core.wmem_max = 212992
net.ipv4.tcp_rmem = 4096        131072  6291456
net.ipv4.tcp_wmem = 4096        16384   4194304
(donc les réglages par défaut d'archlinux)

client : Windows 10 pro fraichement installé et mis a jour.

Lien LAN entre les 2 a 10 Gbits, latence < 1ms donc.
Les  deux sont en bare metal sans virtualization.

IPerf3 :
Windows -> Linux : 3 Gbps
Linux -> Windows : 8 Gbps

Goben:
Windows -> Linux : 9.4 Gbps
Linux -> Windows : 9.4 Gbps

Transfert HTTP avec serveur web maison tournant dans le serveur Linux(mesures débit au dessus de HTTP)
avec Curl: Linux -> Windows : 9.15 Gbps
Avec Wget: Linux -> Windows : 5.28 Gbps

(je n'ai pas encore écrit la version avec un PUT pour tester dans l'autre sens)

Il faut ajouter l'option -w a IPerf3 pour gagner en débit mais elle plante quand on a atteint 2x le net.core.Xmem_max du serveur (soit 425984).

IPerf3 -w 425984:
Windows -> Linux : 7.3 Gbps
Linux -> Windows : 9.4 Gbps

IPerf3 -w 425985 (+1 du max*2) donc:
le serveur affiche:
iperf3: error - socket buffer size not set correctly
quel que ce soit le sens (-R ou pas).

Du coup sans modifier un serveur Linux de base, Windows 10 ne peut envoyer a 10Gbps avec IPerf3 (pas de souci avec Goben). Wget présente des limitations en reception aussi.A priori avec -w, le client iperf3 demande au serveur IPerf3 de changer le socket buffer size meme en reception.

questions/conclusion: doit-on modifier les réglages des OS pour faire fonctionner les applications "mal écrites ?" (iperf3, wget) ou arrêter d'utiliser ces applications pour ces débits la ?

Breizh29

  • Abonné Free fibre
  • *
  • Messages: 408
  • Ergué-Gabéric (29)
FTTH 10G Free: Mesure de débit automatisé avec iPerf3 en IPv4 vs IPv6
« Réponse #183 le: 27 janvier 2020 à 21:42:39 »
Interessant.

Si Vivien est prêt à installer un serveur goben, j’essaierais bien d’adapter le script pour passer d’iperf3 à goben, pour comparer...

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
FTTH 10G Free: Mesure de débit automatisé avec iPerf3 en IPv4 vs IPv6
« Réponse #184 le: 27 janvier 2020 à 22:03:56 »
A noter que mes tests ne sont qu'en LAN (latence < 1ms) sur un lien ou absolument rien d'autre ne passe.
Via Internet avec de latence et d'autres traffics TCP ce n'est plus la meme histoire.

En LAN il semble naturel d'expecter qu'un monoflux puisse atteindre le max sans réglage aucun.
En WAN pas forcement ca va être plus une histoire de compromis. Il ne faut pas oublier que ces histoires de réglages de buffers consomment de la mémoire et peuvent impacter les flux temps réels a base de petits paquets.

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
FTTH 10G Free: Mesure de débit automatisé avec iPerf3 en IPv4 vs IPv6
« Réponse #185 le: 27 janvier 2020 à 23:39:08 »
un autre test:
- serveur go-httpbin modifié coté Windows
- curl coté Linux

curl de 10G:
curl -D - -o /dev/null http://192.168.99.1:8080/stream-bytes/10000000000
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Content-Length: 10000000000
Content-Type: application/octet-stream
Date: Mon, 27 Jan 2020 22:28:11 GMT

100 9536M  100 9536M    0     0  1127M      0  0:00:08  0:00:08 --:--:-- 1129M

1129M = 1129 MiB/s = 9.47 Gbps

Donc un pauvre bout de code en Go (simple boucle au dessus de net.http) arrive a envoyer depuis Windows vers Linux a 10 Gbps la ou IPerf3 plafonne a 3 Gbps ?


hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
FTTH 10G Free: Mesure de débit automatisé avec iPerf3 en IPv4 vs IPv6
« Réponse #186 le: 28 janvier 2020 à 00:11:40 »
iperf3 est compilé avec Cygwin, ça peut peut-être poser problème (en plus du soucis de taille de buffers avec la cygwin1.dll utilisée par Vivien).
Je ne sais pas si on pourrait le compiler avec Mingw par exemple.

je suppose que Go utilise Winsock plus directement.

vivien

  • Administrateur
  • *
  • Messages: 47 080
    • Twitter LaFibre.info
FTTH 10G Free: Mesure de débit automatisé avec iPerf3 en IPv4 vs IPv6
« Réponse #187 le: 28 janvier 2020 à 08:24:27 »
J'ai archivé les graphiques réalisés :







Breizh29, il n'est pas nécessaire de mettre à jour les graphiques ce matin et demain matin.

On est passé à 8h22 en illinois pour 2 jours.
$ cat /proc/sys/net/ipv4/tcp_congestion_control
illinois

L'objectif: pouvoir mieux comparer les débits cubic / illinois en heure en cas de charge.

Le problème du week-end, c'est que la charge est plus importante et que l'on voit des débits plus faibles.
Je veut bien vendredi matin un graphique qui se limite du lundi 00h00 au vendredi matin. On aura donc 2 jours illinois encadré par une journée cubic avant et une journée cubic après.

Breizh29

  • Abonné Free fibre
  • *
  • Messages: 408
  • Ergué-Gabéric (29)
FTTH 10G Free: Mesure de débit automatisé avec iPerf3 en IPv4 vs IPv6
« Réponse #188 le: 28 janvier 2020 à 08:39:33 »
Breizh29, il n'est pas nécessaire de mettre à jour les graphiques ce matin et demain matin.

D'autant que les relevés se sont arrêtés la nuit dernière à 3h20... et que je n'ai pas d'accès pour corriger pour le moment (tunnel VPN freebox qui ne monte pas, accès depuis l'app iOS de supervision OK, mais désactivation/réactivation serveur VPN inopérante. Par ailleurs, des flux sortants passent...). Bref je ne sais pas encore d'où vient le problème.
Et ce ne sera peut-être corrigé que ce soir...

EDIT: bon serveur VPN revenu (?) mais connexion ssh au mac impossible. Probablement planté.

Sinon, partant pour quelques expérimentations goben ?

Breizh29

  • Abonné Free fibre
  • *
  • Messages: 408
  • Ergué-Gabéric (29)
FTTH 10G Free: Mesure de débit automatisé avec iPerf3 en IPv4 vs IPv6
« Réponse #189 le: 28 janvier 2020 à 11:21:06 »
Et à présent, incident quasi généralisé Free sur le sud finistère on dirait (cf. free-reseau.fr)

Breizh29

  • Abonné Free fibre
  • *
  • Messages: 408
  • Ergué-Gabéric (29)
FTTH 10G Free: Mesure de débit automatisé avec iPerf3 en IPv4 vs IPv6
« Réponse #190 le: 28 janvier 2020 à 18:43:10 »
Bon, j'ai essayé de relancer le bouzin, mais à présent, j'ai "connection refused" sur tous les ports, de nouveau.
Tout va bien côté serveur ?

darkmoon

  • Abonné Free fibre
  • *
  • Messages: 730
  • ↓ 5 Gbps | ↑ 700Mbps (SGL 69)
FTTH 10G Free: Mesure de débit automatisé avec iPerf3 en IPv4 vs IPv6
« Réponse #191 le: 28 janvier 2020 à 20:29:04 »
Même soucis ... depuis 16h30~17h plus rien