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

Breizh29 · « **Réponse #72 le:** 13 janvier 2020 à 13:08:13 »

Oui, Vivien avait vérifié.
Concernant IPv4 / IPv6, j'avais déjà fait cette remarque au début des tests. Cet écart avait disparu avec Cubic, et est revenu depuis que Vivien a remis Illinois.

Florian · « **Réponse #73 le:** 13 janvier 2020 à 13:14:06 »

Ok, merci pour les précisions

vivien · « **Réponse #74 le:** 13 janvier 2020 à 14:29:17 »

Citation de: kgersen le 13 janvier 2020 à 12:36:43

A mon avis, Illinois n'a aucun intérêt. Il date d'avant cubic.

Pourtant la plupart des outil de test débit recommandent de changer Cubis par Illinois.
Je reconnais que ce n'est pas super représentatif d'où mon intérêt pour BBR, plus représentatif.

Citation de: kgersen le 13 janvier 2020 à 12:36:43

Pour un serveur speedtest dédié, ce qui est plus inquiétant est d'utiliser Ubuntu 18.04 plutôt qu'une distrib plus a jour niveau kernel/driver (archlinux par exemple).

J'ai fait un comparatif il y a quelques années de différents OS serveur et Ubuntu arrivait clairement en tête : https://lafibre.info/serveur-linux/comparatif-os-server/
(pour ce comparatif, je suis resté avec les paramètres par défaut proposés)

Pour le noyaux Linux utilisé, il est régulièrement mis à jour. Si tu installe Ubuntu 18.04.4, tu peut voir que le noyau par défaut est le noyau HWE, aujourd'hui en version 5.3

Pour le parc installé avec le noyau HWE, la migration du noyau 5.0 vers le noyau 5.3 va intervenir cette semaine. Si vous n'êtes pas sur un noyau HWE, le commande sont dans le sujet Linux 4.18 : gain de performance sur certains serveurs

kgersen · « **Réponse #75 le:** 13 janvier 2020 à 16:24:34 »

Mon point c'est juste que Ubuntu n'est pas de base une distro de type 'Rolling release'. T'es obligé de faire la manip que t'indique pour avoir un pseudo rolling release partiel du noyau. Dans le cadre d'un usage desktop ou server généraliste (si cette notion existe...) pourquoi pas mais dans le cadre d'un serveur dédié test de débit une distro rolling release a plus de sens. Par exemple ton iperf3 n'est pas a jour car tu dépend des packages Ubuntu.

Pour ce qui est des comparatifs de performance pour moi ca n'a pas de sens, une bonne installation doit être 'tuner' par rapport a l'usage qu'on veut en faire. Un comparatif 'synthétique' généraliste n'apporte aucune information utile si on veut faire un serveur speedtest (iperf ou autre) dédié.

Breizh29 · « **Réponse #76 le:** 14 janvier 2020 à 09:07:53 »

Mise à jour de ce matin 8h.
Comme on pouvait le supposer, on retrouve le comportement Illinois du début avec des amplitudes moindres.
D'un côté cela homogénéise les débits, comme Vivien l'a dit précédemment, de l'autre, c'est dommage, pour un serveur de speedtest, de ne pas livrer un résultat plus proche du max possible de la connexion...

@Vivien :
Nouvelles optimisations prévues ? ou on essaie un autre algo ? ou autre ?

vivien · « **Réponse #77 le:** 14 janvier 2020 à 10:25:57 »

a 10h20, je suis passé de fq_codel à fq :

Avant :
# tc qdisc show qdisc noqueue 0: dev lo root refcnt 2 qdisc mq 0: dev enp1s0f0 root qdisc fq_codel 0: dev enp1s0f0 parent :10 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn qdisc fq_codel 0: dev enp1s0f0 parent :f limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn qdisc fq_codel 0: dev enp1s0f0 parent :e limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn qdisc fq_codel 0: dev enp1s0f0 parent :d limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn qdisc fq_codel 0: dev enp1s0f0 parent :c limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn qdisc fq_codel 0: dev enp1s0f0 parent :b limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn qdisc fq_codel 0: dev enp1s0f0 parent :a limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn qdisc fq_codel 0: dev enp1s0f0 parent :9 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn qdisc fq_codel 0: dev enp1s0f0 parent :8 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn qdisc fq_codel 0: dev enp1s0f0 parent :7 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn qdisc fq_codel 0: dev enp1s0f0 parent :6 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn qdisc fq_codel 0: dev enp1s0f0 parent :5 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn qdisc fq_codel 0: dev enp1s0f0 parent :4 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn qdisc fq_codel 0: dev enp1s0f0 parent :3 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn qdisc fq_codel 0: dev enp1s0f0 parent :2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn qdisc fq_codel 0: dev enp1s0f0 parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn

Après :
# tc qdisc add dev enp1s0f0 root fq # tc qdisc show qdisc noqueue 0: dev lo root refcnt 2 qdisc fq 8001: dev enp1s0f0 root refcnt 65 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms

Breizh29 · « **Réponse #78 le:** 15 janvier 2020 à 08:31:03 »

Mise à jour de ce matin 8h20 après une apm / soirée / nuit de test.
Le résultat est plutôt médiocre, ça semble plutôt se détériorer par rapport à l'ancien paramétrage.

Vivien, qu'envisages-tu pour la suite, le cas échéant ?

DamienC · « **Réponse #79 le:** 15 janvier 2020 à 10:37:51 »

Hello, je me joins à la partie samedi, j'aurai mon accès Freebox 10G.

Breizh29 · « **Réponse #80 le:** 15 janvier 2020 à 12:18:55 »

Depuis 12h10, chute de presque 2 Gbits/s...
Hasard ou Vivien a touché aux réglages ?

EDIT: ça se confirme à 12h20 (baisse encore un peu...)

vivien · « **Réponse #81 le:** 15 janvier 2020 à 12:28:17 »

Je confirme, mon fichier avec les optimisation n'est plus pris en compte.

J'ai cherché et j'ai compris pourquoi net.core.default_qdisc=fq n'était pas pris en compte : il était appliqué trop tôt.

J'ai donc supprimer le fichier /etc/sysctl.d/19-patch-swappiness.conf pour mettre /etc/sysctl.d/90-server-optimization

90 arrivant après 19, la configuration est cette fois-ci bonne (j'ai fais les test sur Ubuntu 19.10)

Dans les modifications il y a aussi :
net.ipv4.tcp_wmem=4096 65536 16777216
par :
net.ipv4.tcp_wmem=4096 87380 16777216
87380 fait parti des recommandations "IBM's High Performance Computing page"

Coté rmem on passe de :
net.ipv4.tcp_rmem=4096 87380 16777216
A :
net.ipv4.tcp_rmem=4096 131072 16777216

Voici le fichier :

nano /etc/sysctl.d/90-server-optimization

Code: [Sélectionner]

# Reduce the swap
vm.swappiness = 1

# Reduce the threshold where a DDOS impacts the server
net.ipv4.tcp_max_syn_backlog = 4096

# TCP congestion control protocol for high-speed and long-distance networks
net.ipv4.tcp_congestion_control=illinois
#net.ipv4.tcp_congestion_control=bbr

# Désactiver la mémorisation des tests précédents afin d'éviter que le serveur bride les tests suite à une performances limitée
net.ipv4.tcp_no_metrics_save=1

# 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

# default queuing discipline for 10GigE speeds
net.core.default_qdisc=fq

# Increase the queue within the Linux kernel where traffic is stored after reception from the NIC
net.core.netdev_max_backlog=4000

# Increase number of incoming connections
net.core.somaxconn = 512

Là le gros souci c'est que aucune de ces optimisation n'est prise en compte.

Je bosse dessus.

Breizh29 · « **Réponse #82 le:** 15 janvier 2020 à 12:30:56 »

OK merci.
Bon courage.

vivien · « **Réponse #83 le:** 15 janvier 2020 à 13:01:30 »

erreur de débutant, j'ai oublié un .conf à l'extension du fichier (et j'ai cherché a beaucoup d'autres choses avant de trover)

C'est ok depuis 12h58

Je suis intéressé pour les données entre les deux.

Outre l'augmentation de la Rwin expliquée avant, on a donc maintenant un fq différent.

Avant je passais en fq via la commande tc qdisc add dev enp1s0f0 root fq, maintenant c'est via net.core.default_qdisc=fq qui est dans le fichier /etc/sysctl.d/90-server-optimization.conf

Avant :

Code: [Sélectionner]

# tc qdisc show
qdisc noqueue 0: dev lo root refcnt 2
qdisc fq 8001: dev enp1s0f0 root refcnt 65 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms

Maintenant :

Code: [Sélectionner]

$ tc qdisc show 
qdisc noqueue 0: dev lo root refcnt 2 
qdisc mq 0: dev enp1s0f0 root 
qdisc fq 0: dev enp1s0f0 parent :10 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms 
qdisc fq 0: dev enp1s0f0 parent :f limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms 
qdisc fq 0: dev enp1s0f0 parent :e limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms 
qdisc fq 0: dev enp1s0f0 parent :d limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms 
qdisc fq 0: dev enp1s0f0 parent :c limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms 
qdisc fq 0: dev enp1s0f0 parent :b limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms 
qdisc fq 0: dev enp1s0f0 parent :a limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms 
qdisc fq 0: dev enp1s0f0 parent :9 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms 
qdisc fq 0: dev enp1s0f0 parent :8 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms 
qdisc fq 0: dev enp1s0f0 parent :7 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms 
qdisc fq 0: dev enp1s0f0 parent :6 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms 
qdisc fq 0: dev enp1s0f0 parent :5 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms 
qdisc fq 0: dev enp1s0f0 parent :4 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms 
qdisc fq 0: dev enp1s0f0 parent :3 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms 
qdisc fq 0: dev enp1s0f0 parent :2 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms 
qdisc fq 0: dev enp1s0f0 parent :1 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms