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

vivien · « **Réponse #156 le:** 23 janvier 2020 à 09:09:48 »

9h03 : initcwnd 90 supprimé.
Cela devrait un impact important sur le monothread.
C'est peut-être ça qui entraînait de nombreuses retransmissions.

Avant :

$ ip -4 route list default via 89.84.1.185 dev enp1s0f0 initcwnd 90 89.84.1.184/29 dev enp1s0f0 proto kernel scope link src 89.84.1.186 89.84.1.220/30 dev enp1s0f0 proto kernel scope link src 89.84.1.222 $ ip -6 route list ::1 dev lo proto kernel metric 256 pref medium 2001:860:de01:1100::/64 dev enp1s0f0 proto kernel metric 256 pref medium 2001:860:deff:1000::/64 dev enp1s0f0 proto kernel metric 256 pref medium fe80::/64 dev enp1s0f0 proto kernel metric 256 pref medium default via 2001:860:de01:1100::1 dev enp1s0f0 metric 1024 initcwnd 90 pref medium

Maintenant :

$ ip -4 route list default via 89.84.1.185 dev enp1s0f0 onlink 89.84.1.184/29 dev enp1s0f0 proto kernel scope link src 89.84.1.186 89.84.1.220/30 dev enp1s0f0 proto kernel scope link src 89.84.1.222 $ ip -6 route list ::1 dev lo proto kernel metric 256 pref medium 2001:860:de01:1100::/64 dev enp1s0f0 proto kernel metric 256 pref medium 2001:860:deff:1000::/64 dev enp1s0f0 proto kernel metric 256 pref medium fe80::/64 dev enp1s0f0 proto kernel metric 256 pref medium default via 2001:860:de01:1100::1 dev enp1s0f0 metric 1024 onlink pref medium

Citation de: kgersen le 22 janvier 2020 à 19:16:16

j'ai 90% du temps un 'occupé' quand je tente un iperf3 sur ce serveur

Il y a 10 ports iperf3 ouverts, pas uniquement le port par défaut.

UDP est ouvert si tu souhaites faire des tests.

kgersen · « **Réponse #157 le:** 23 janvier 2020 à 18:53:27 »

Citation de: vivien le 23 janvier 2020 à 09:09:48

Il y a 10 ports iperf3 ouverts, pas uniquement le port par défaut.

oui je comptais ces ports dans mes tentatives.

par exemple a l'instant, je tente 3 fois sur 3 ports différents. 3 échecs.

Code: [Sélectionner]

[~]$ iperf3 -4 -c paris.testdebit.info -P 4 -R -V --get-server-output -b 100M
iperf 3.7
iperf3: error - the server is busy running a test. try again later
[~]$ iperf3 -4 -c paris.testdebit.info -P 4 -R -V --get-server-output -b 100M -p 5207
iperf 3.7
iperf3: error - the server is busy running a test. try again later
[~]$ iperf3 -4 -c paris.testdebit.info -P 4 -R -V --get-server-output -b 100M -p 5204
iperf 3.7
iperf3: error - the server is busy running a test. try again later

Je testerais UDP plus tard.

Breizh29 · « **Réponse #158 le:** 24 janvier 2020 à 08:39:43 »

Mise à jour de ce matin 8h20

Logan21 · « **Réponse #159 le:** 24 janvier 2020 à 09:03:18 »

et en upload, ça donne quoi?

Breizh29 · « **Réponse #160 le:** 24 janvier 2020 à 09:47:30 »

On ne l'a pas (encore ?) inclus dans le périmètre, il n'est pas mesuré.
C'était moins un sujet vu la forte asymétrie DL/UL et qu'on s'intéressait aux débits entre 1 et 10 gbps.

vivien · « **Réponse #161 le:** 24 janvier 2020 à 12:07:40 »

La suppression de initcwnd 90 n'a eu aucun impact.

Les évolutions du tcp_congestion_control :
- 17 janvier 9h32 Illinois => Cubic
- 20 janvier 8h12 Cubic => BBR
- 22 janvier 10h03 BBR => Illinois (on n'avais pas de tests mono-thread en Illinois)
- 24 janvier 11h52 Illinois => Cubic

Actuellement :
$ cat /proc/sys/net/ipv4/tcp_congestion_control cubic

Cubic semble clairement bien mieux que Illinois en multithread.
En monothread, Cubic semble un peu moins bon que Illinois, mais c'est à peine visible.

Breizh29 · « **Réponse #162 le:** 24 janvier 2020 à 12:53:15 »

Citation de: vivien le 24 janvier 2020 à 12:07:40

En monothread, Cubic semble un peu moins bon que Illinois, mais c'est à peine visible.

Pas si invisible que ça (j'aurais trouvé le changement sans que tu ne l'évoques).
Chiffres du matin :

Code: [Sélectionner]

24/01/2020 10:00:00 ; 6,15 ; 5,89 ; 4,17 ; 6,00
24/01/2020 10:10:00 ; 6,28 ; 5,82 ; 4,58 ; 5,01
24/01/2020 10:20:00 ; 6,30 ; 5,88 ; 5,22 ; 2,95
24/01/2020 10:30:01 ; 6,24 ; 5,90 ; 5,07 ; 5,22
24/01/2020 10:40:00 ; 6,27 ; 5,86 ; 5,32 ; 5,74
24/01/2020 10:50:00 ; 6,43 ; 5,89 ; 4,83 ; 5,71
24/01/2020 11:00:00 ; 6,22 ; 6,22 ; 5,04 ; 5,03
24/01/2020 11:10:00 ; 6,24 ; 5,89 ; 4,88 ; 5,94
24/01/2020 11:20:00 ; 6,08 ; 5,78 ; 4,16 ; 5,80
24/01/2020 11:30:01 ; 6,27 ; 6,03 ; 5,81 ; 5,42
24/01/2020 11:40:00 ; 6,25 ; 5,82 ; 5,19 ; 5,72
24/01/2020 11:50:00 ; 6,28 ; 5,79 ; 5,23 ; 5,69
24/01/2020 12:00:00 ; 6,41 ; 6,94 ; 1,51 ; 1,00 
24/01/2020 12:10:00 ; 6,95 ; 6,84 ; 1,98 ; 1,32
24/01/2020 12:20:00 ; 4,16 ; 6,77 ; 0,34 ; 3,79
24/01/2020 12:30:00 ; 5,03 ; 7,05 ; 0,30 ; 1,38
24/01/2020 12:40:00 ; 6,22 ; 6,23 ; 2,24 ; 2,61

Je suis d'accord qu'étant sur un serveur à vocation de speedtest, il faut pouvoir monter autant que possible, donc cubic semble plus adapté qu'Illinois.
En revanche, s'il y a encore des marges de manoeuvre, une optimisation en cubic serait la bienvenue pour éviter de tomber si bas en période chargée, ou au moins plus tard dans la journée.

vivien · « **Réponse #163 le:** 24 janvier 2020 à 13:09:35 »

Je suis d’accord avec tes données Cubic semble plus pertinent que les autres.
Il a l'avantage également de la représentativité.

Je me demande par contre si les résultats pourraient être différent avec un Linux ou un Windows en client.

Je veux bien la mise à jour des graphiques demain matin, cela permettra de faire un résumé graphiques des principaux tests réalisés.

Tu as un Mac mini (i7 3,2 GHz) : Serait-il possible d'avoir la référence complète du CPU ?

Breizh29 · « **Réponse #164 le:** 24 janvier 2020 à 14:01:07 »

Citation de: vivien le 24 janvier 2020 à 13:09:35

Je me demande par contre si les résultats pourraient être différent avec un Linux ou un Windows en client.

J'ai envisagé un multiboot MacOS / Win / Linux (d'ailleurs, j'ai déjà une partition bootcamp : Win 10 sans virtualisation est possible)
Reste à voir pour un Linux.
En tous les cas, il faut passer un peu de temps d'optimisation... et je ne peux pas conserver la machine dans la durée sur un autre OS (je l'utilise, quand même...).

<HS>
J'avais pour projet d'acquérir/ monter un serveur (d'occasion, probablement) pour ça et d'autres choses. Idéalement, j'aurais voulu mettre à ESXi ou assimilé et monter plusieurs VMs, avec une carte 10G. Je l'aurais placé à proximité de ma baie. Tu aurais une idée pour profiter de 10G, idéalement au sein des machines virtuelles, sans y laisser 2 bras ?
</HS>

Citation de: vivien le 24 janvier 2020 à 13:09:35

Je veux bien la mise à jour des graphiques demain matin, cela permettra de faire un résumé graphiques des principaux tests réalisés.

Sauf imprévu, ce sera comme d'hab.

Citation de: vivien le 24 janvier 2020 à 13:09:35

Tu as un Mac mini (i7 3,2 GHz) : Serait-il possible d'avoir la référence complète du CPU ?

Je regarde ça asap et je reprécise.
EDIT : I7-8700B

vivien · « **Réponse #165 le:** 24 janvier 2020 à 14:10:43 »

darkmoon a un iPerf3 est lui aussi chez Free, il a un serveur Linux (1 Gb/s) qui utilise le même serveur.

Les résultats sont assez plats malgré toutes nos modifications (il a 8 connexion TCP en //)

On note une baisse de débit le dimanche soir, jour de la plus forte consommation de bande passante.

Citation de: vivien le 24 janvier 2020 à 14:08:19

Voici ce que cela donne comme graphique : (merci darkmoon)

darkmoon · « **Réponse #166 le:** 24 janvier 2020 à 14:54:27 »

A noter que je ne fais les tests (down & up) qu'en ipv6.

Code: [Sélectionner]

mtr -zwc5 -6 bouygues.iperf.fr
Start: 2020-01-24T14:49:09+0100
HOST: Freeze                              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS12322  2a01:e0a:1dx:xyzw::1         0.0%     5    1.1   1.1   1.0   1.3   0.1
  2. AS12322  2a01:e02:1:f836:8917::ffff   0.0%     5    2.7   3.4   2.7   4.3   0.6
  3. AS12322  2a01:e02:1:1735::ffff       80.0%     5    2.8   2.8   2.8   2.8   0.0
  4. AS???    ???                         100.0     5    0.0   0.0   0.0   0.0   0.0
  5. AS12322  2a01:e00:3f::5               0.0%     5   10.1  10.0   9.7  10.2   0.2
  6. AS5410   2001:860:0:81::1             0.0%     5    9.7   9.7   9.5  10.0   0.2
  7. AS5410   2001:860:bbee:b4::2          0.0%     5    9.8  10.0   9.8  10.4   0.2
  8. AS5410   2001:860:bbe0:128::2         0.0%     5   11.1  10.8  10.3  11.2   0.4
  9. AS5410   2001:860:deff:1000::2        0.0%     5   10.2   9.7   9.1  10.2   0.4

Un jour peut-être j'aurais de l'argent à dépenser dans du matos 10G

vivien · « **Réponse #167 le:** 24 janvier 2020 à 18:24:11 »

Thornhill, voici les valeur par défaut :
• net.ipv4.tcp_rmem=4096 131072 6291456
• net.ipv4.tcp_wmem=4096 16384 4194304
• net.core.rmem_max= 212992
• net.core.wmem_max= 212992

C'est étonnant que rmem_max ne soit pas aligné sur la valeur max de net.ipv4.tcp_rmem, non ?

Idem pour wmem_max qui n'est pas aligné sur la valeur max de net.ipv4.tcp_wmem

Citation de: Thornhill le 15 janvier 2020 à 17:43:10

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.

La valeur optimisé pour des haut débit avec une forte latence serait ça ?
• net.ipv4.tcp_rmem=4096 131072 16777216
• net.ipv4.tcp_wmem=4096 87380 16777216
• net.core.rmem_max=16777216
• net.core.wmem_max=16777216

Je me demande si la valeur de 16 Mo peut être utilisée.
Il n'y a pas de win_scale_factor limité à 7 avec certains OS ?

Coté Mac le net.inet.tcp.win_scale_factor par défault est de 3 ou 5 selon les version de MacOS X