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

vivien · « **Réponse #120 le:** 18 janvier 2020 à 16:53:56 »

Le serveur a été presque 24h avec Cubic + qdisc=fq et les débits sont restés comme en illinois, avec un meilleur débit en IPv4 vs IPv6.

Citation de: vivien le 17 janvier 2020 à 09:37:43

Depuis 9h32 on est passé en cubic pour l'algorithme d'évitement de congestion TCP.

Avant on était en illinois.

Citation de: kgersen le 18 janvier 2020 à 15:48:52

"tc -s qdisc show dev enp1s0f0" c'est plus utile.

Voila :

Code: [Sélectionner]

$ tc -s qdisc show dev enp1s0f0
qdisc mq 0: root 
 Sent 2882198390815 bytes 2059419059 pkt (dropped 0, overlimits 0 requeues 72039) 
 backlog 0b 0p requeues 72039
qdisc fq_codel 0: parent :10 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn 
 Sent 356733539433 bytes 257715765 pkt (dropped 0, overlimits 0 requeues 5856) 
 backlog 0b 0p requeues 5856
  maxpacket 68264 drop_overlimit 0 new_flow_count 37136 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :f limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn 
 Sent 730126997402 bytes 513812841 pkt (dropped 0, overlimits 0 requeues 23906) 
 backlog 0b 0p requeues 23906
  maxpacket 68264 drop_overlimit 0 new_flow_count 149626 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :e limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn 
 Sent 345974573962 bytes 247635138 pkt (dropped 0, overlimits 0 requeues 5230) 
 backlog 0b 0p requeues 5230
  maxpacket 68264 drop_overlimit 0 new_flow_count 36085 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :d limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn 
 Sent 682679426134 bytes 480775485 pkt (dropped 0, overlimits 0 requeues 22553) 
 backlog 0b 0p requeues 22553
  maxpacket 68796 drop_overlimit 0 new_flow_count 130776 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :c limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn 
 Sent 183780202712 bytes 132185123 pkt (dropped 0, overlimits 0 requeues 2898) 
 backlog 0b 0p requeues 2898
  maxpacket 68796 drop_overlimit 0 new_flow_count 11586 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :b limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn 
 Sent 184874910117 bytes 135001884 pkt (dropped 0, overlimits 0 requeues 3509) 
 backlog 0b 0p requeues 3509
  maxpacket 68264 drop_overlimit 0 new_flow_count 15505 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :a limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn 
 Sent 197856694076 bytes 147393790 pkt (dropped 0, overlimits 0 requeues 4581) 
 backlog 0b 0p requeues 4581
  maxpacket 68796 drop_overlimit 0 new_flow_count 32582 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :9 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn 
 Sent 200172044499 bytes 144899011 pkt (dropped 0, overlimits 0 requeues 3506) 
 backlog 0b 0p requeues 3506
  maxpacket 68130 drop_overlimit 0 new_flow_count 19855 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :8 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn 
 Sent 220 bytes 2 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
  maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :7 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn 
 Sent 110 bytes 1 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
  maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :6 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn 
 Sent 110 bytes 1 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
  maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :5 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn 
 Sent 110 bytes 1 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
  maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :4 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn 
 Sent 680 bytes 6 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
  maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :3 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn 
 Sent 330 bytes 3 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
  maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn 
 Sent 480 bytes 4 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
  maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn 
 Sent 440 bytes 4 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
  maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
  new_flows_len 0 old_flows_len 0

Je n'ai pas bien compris, tu ne me conseillait pas de mettre fq pour le qudisc, à la place du fq_codel ?

Citation de: kgersen le 07 janvier 2020 à 16:56:33

en 2020, tout le monde devrait être en BBR mais pas mal de distro ne font pas l'effort de le mettre par défaut.

pour changer:

Code: [Sélectionner]
sudo sysctl net.ipv4.tcp_congestion_control=bbr sudo sysctl net.core.default_qdisc=fq(le qdisc est optionnel depuis le kernel 4.13 mais autant mettre fq dans des machines d'extrémités (serveur, client) plutot que fq_codel le défaut plutôt utile sur routeur).

Donc si je comprends bien avec un kernel récent on ne touche pas au qdsic (il n'y a pas qu'iPerf sur ce serveur, il y a aussi Apache également pour des tests de débit)

Harvester · « **Réponse #121 le:** 18 janvier 2020 à 20:48:06 »

Ce n'est peut-être plus pertinent, mais le wiki bufferbloat recommande ceci :

Citer

For servers with tcp-heavy workloads, particularly at 10GigE speeds, for queue management, we recomend sch_fq instead of fq_codel as of linux 3.12.

(Tiré de : https://www.bufferbloat.net/projects/codel/wiki/#binary-code-and-kernels-for-linux-based-operating-systems)

EDIT :

Commentaire plus récent (2018) sur GitHub (le reste du thread est intéressant aussi) : https://github.com/systemd/systemd/issues/9725#issuecomment-412286509

Citer

sch_fq is for tcp-serving heavy workloads, primarily from the datacenter, and does nothing sane for other forms of traffic including acks in the reverse direction. IF all you are doing is tcp serving at 10gigE+, sch_fq is totally the right thing. Otherwise it can actually be worse than pfifo_fast! At 1gigE, sch_fq's defaults are set too high (for example) for even your typical nas or laptop.

vivien · « **Réponse #122 le:** 19 janvier 2020 à 08:14:49 »

8h13 : J'ai juste remis la ligne net.core.default_qdisc=fq dans mon fichier /etc/sysctl.d/90-server-optimization.conf pour quelques heures afin de vérifier qu'il y a bien de nouveau une forte dégradation des débits.

Ensuite je passerais à BBR

Breizh29 · « **Réponse #123 le:** 19 janvier 2020 à 11:59:40 »

Surprise en monothread le nuit dernière, où bien que l'instabilité soit de mise, j'ai réussi à atteindre des niveaux de débit proches du max multithread et du théorique tout court.
Hier soir, j'ai ré-appliqué des modifications sur la pile TCP (taille des buffers largement augmentée...) que j'avais entreprises avant la réalisation du graphe monothread, et qui doivent probablement expliquer ce phénomène.

Mais pourquoi est-il si flagrant, et uniquement en heures très creuses ? J'avoue que l'ampleur m'étonne, tout comme les brutalités de la hausse et surtout de la baisse.

Pour détails, voici les chiffres depuis ce matin 1h, heure à laquelle j'ai stoppé toute intervention sur ma machine :

Code: [Sélectionner]

Date ; IPv4 multi ; IPv6 multi ; IPv4 mono ; IPv6 mono
20200119 01:00:00	5,42	6,47	0,37	1,59
20200119 01:10:00	5,72	6	0,65	0,8
20200119 01:20:00	6,29	6,95	0,99	1,22
20200119 01:30:00	6,85	7,03	1,2	2,36
20200119 01:40:00	6,3	7,17	1,24	2,5
20200119 01:50:01	6,75	7,03	1,32	1,42
20200119 02:00:00	6,66	7,11	1,78	4,14
20200119 02:10:00	6,58	7,39	1,84	3,21
20200119 02:20:00	6,92	7,48	2,34	2,46
20200119 02:30:01	6,85	7,38	2,38	2,02
20200119 02:40:00	7,04	7,45	1,43	6,09
20200119 02:50:00	6,9	7,38	2,55	4,67
20200119 03:00:00	6,99	7,44	2,37	3,45
20200119 03:10:00	7,03	7,37	3,6	5,87
20200119 03:20:00	6,35	7,31	5,15	4,41
20200119 03:30:00	7,16	7,44	4,94	4,79
20200119 03:40:00	7,12	7,41	2,33	7,2
20200119 03:50:00	6,95	7,34	1,73	5,54
20200119 04:00:00	7,31	7,62	3,04	6,87
20200119 04:10:00	7,23	7,21	3,86	6,61
20200119 04:20:00	7,4	7,56	2,12	6,45
20200119 04:30:00	7,1	7,65	6,51	5,2
20200119 04:40:00	7,48	7,6	7,1	6,5
20200119 04:50:00	7,46	7,68	6,66	6,63
20200119 05:00:00	7,25	7,63	5,2	7,08
20200119 05:10:00	7,08	7,34	5,75	7,1
20200119 05:20:00	7,51	7,64	6,32	3,46
20200119 05:30:00	7,52	7,71	6,3	7,2
20200119 05:40:00	7,6	7,59	5,81	7,09
20200119 05:50:01	7,66	7,7	3,4	6,18
20200119 06:00:00	7,46	7,68	4,52	7,18
20200119 06:10:00	7,38	7,56	2,54	7,19
20200119 06:20:01	7,75	7,63	4,68	7,1
20200119 06:30:00	7,45	7,7	7,08	7
20200119 06:40:01	7,42	7,16	5,07	6,37
20200119 06:50:00	7,54	7,62	3,94	4,92
20200119 07:00:00	7,68	7,36	6,17	7,03
20200119 07:10:00	7,54	7,51	7,09	7,19
20200119 07:20:00	7,55	7,46	5,61	2,8
20200119 07:30:00	7,45	7,68	4,01	6,92
20200119 07:40:00	7,64	7,66	5,33	1,54
20200119 07:50:01	7,57	7,51	3,76	2,52
20200119 08:00:00	7,52	7,8	3,25	5,16
20200119 08:10:00	7,28	7,56	1,16	7,18
20200119 08:20:00	7,06	7,15	4,47	5,19
20200119 08:30:01	7,22	7,57	2,48	6,54
20200119 08:40:00	7,26	7,15	4,46	6,7
20200119 08:50:00	7,12	7,22	4,15	3,97
20200119 09:00:01	7,18	7,13	0,53	3,32
20200119 09:10:00	6,58	6,11	1,06	1,7
20200119 09:20:00	6,25	6,46	1,59	1,59
20200119 09:30:01	6,49	6,49	1,01	1,33
20200119 09:40:00	6,44	6,31	2,08	1,32
20200119 09:50:00	6,46	6,7	0,97	0,49
20200119 10:00:00	6,39	6,71	0,54	1,8
20200119 10:10:00	6,26	6,44	0,96	1,24
20200119 10:20:00	6,35	6,6	1,02	1,58
20200119 10:30:00	5	5,06	1,26	1,46
20200119 10:40:01	5,78	5,8	0,93	0,55
20200119 10:50:00	5,77	6,02	1,18	0,74
20200119 11:00:00	5,91	6,05	0,77	1,31
20200119 11:10:00	5,91	6,33	0,84	1,02
20200119 11:20:00	5,96	6,22	0,57	0,83
20200119 11:30:00	4,78	5,98	0,59	1,28
20200119 11:40:00	6,09	5,7	0,78	1,39

@Vivien : si tu souhaites les mesures de certains créneaux horaires pour analyser toi-même les impacts de tes changements, fais le moi savoir.

vivien · « **Réponse #124 le:** 19 janvier 2020 à 12:52:54 »

Les graphiques :

Citation de: Breizh29 le 19 janvier 2020 à 11:59:40

@Vivien : si tu souhaites les mesures de certains créneaux horaires pour analyser toi-même les impacts de tes changements, fais le moi savoir.

Il serait intéressant de garder les graphiques historique et de mettre sur un graphique qui commence le 19/01 les 4 tests sur le même graphique avec 4 couleurs différentes

Tu fait comment pour générer ces graphiques avec une aussi grande résolution ? Je supposait que c'était Excel mais je ne vois pas de fonction d'export (et vu la résolution cela ne dois pas être une capture d'écran, sauf si tu es en 4k)

Je note que en monothread tu as un meilleur débit en IPv6.

Finalement, le week-end la saturation démarre tôt (il y a bien une baisse à 8h00, mais pas sur que cela soit ma modification) et il n'est pas pertinent de faire une seconde modification en cours de journée.

Je passe en BBR demain matin.

kgersen · « **Réponse #125 le:** 19 janvier 2020 à 12:58:29 »

Oui impressionnant l'écart. On n'a pas de visibilité sur ce qui passe coté serveur (crosstalk notamment) du coup difficile de dire ou est la cause.

par contre :

Citation de: vivien le 18 janvier 2020 à 16:53:56

Le serveur a été presque 24h avec Cubic + qdisc=fq et les débits sont restés comme en illinois, avec un meilleur débit en IPv4 vs IPv6.
Voila :
Code: [Sélectionner]
$ tc -s qdisc show dev enp1s0f0 qdisc mq 0: root Sent 2882198390815 bytes 2059419059 pkt (dropped 0, overlimits 0 requeues 72039) backlog 0b 0p requeues 72039 qdisc fq_codel 0: parent :10 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 356733539433 bytes 257715765 pkt (dropped 0, overlimits 0 requeues 5856) backlog 0b 0p requeues 5856 maxpacket 68264 drop_overlimit 0 new_flow_count 37136 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 0: parent :f limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 730126997402 bytes 513812841 pkt (dropped 0, overlimits 0 requeues 23906) backlog 0b 0p requeues 23906 maxpacket 68264 drop_overlimit 0 new_flow_count 149626 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 0: parent :e limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 345974573962 bytes 247635138 pkt (dropped 0, overlimits 0 requeues 5230) backlog 0b 0p requeues 5230 maxpacket 68264 drop_overlimit 0 new_flow_count 36085 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 0: parent :d limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 682679426134 bytes 480775485 pkt (dropped 0, overlimits 0 requeues 22553) backlog 0b 0p requeues 22553 maxpacket 68796 drop_overlimit 0 new_flow_count 130776 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 0: parent :c limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 183780202712 bytes 132185123 pkt (dropped 0, overlimits 0 requeues 2898) backlog 0b 0p requeues 2898 maxpacket 68796 drop_overlimit 0 new_flow_count 11586 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 0: parent :b limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 184874910117 bytes 135001884 pkt (dropped 0, overlimits 0 requeues 3509) backlog 0b 0p requeues 3509 maxpacket 68264 drop_overlimit 0 new_flow_count 15505 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 0: parent :a limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 197856694076 bytes 147393790 pkt (dropped 0, overlimits 0 requeues 4581) backlog 0b 0p requeues 4581 maxpacket 68796 drop_overlimit 0 new_flow_count 32582 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 0: parent :9 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 200172044499 bytes 144899011 pkt (dropped 0, overlimits 0 requeues 3506) backlog 0b 0p requeues 3506 maxpacket 68130 drop_overlimit 0 new_flow_count 19855 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 0: parent :8 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 220 bytes 2 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 0: parent :7 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 110 bytes 1 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 0: parent :6 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 110 bytes 1 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 0: parent :5 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 110 bytes 1 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 0: parent :4 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 680 bytes 6 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 0: parent :3 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 330 bytes 3 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 0: parent :2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 480 bytes 4 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 440 bytes 4 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0

ca fait beaucoup de lignes la je trouve. t'as configurer comment ton qdisc ?

reset:

Code: [Sélectionner]

sudo tc -p qdisc delete dev enp1s0f0 rootpuis ajoute

Code: [Sélectionner]

sudo tc -p qdisc add dev enp1s0f0 root fq_codel (ou fq)

Citation de: vivien le 18 janvier 2020 à 16:53:56

Je n'ai pas bien compris, tu ne me conseillait pas de mettre fq pour le qudisc, à la place du fq_codel ?
Donc si je comprends bien avec un kernel récent on ne touche pas au qdsic (il n'y a pas qu'iPerf sur ce serveur, il y a aussi Apache également pour des tests de débit)

oui fallait mettre fq si le kernel est ancien car bbr nécessite impérativement fq sur un ancien kernel. Sur un nouveau kernel on peut garder le qdisc en place.
Apres dans le code source de BBR il est mentionné que ne pas mettre fq engendre plus de conso de ressource. Donc autant mettre fq quand on utilise bbr.

vivien · « **Réponse #126 le:** 19 janvier 2020 à 13:18:58 »

Citation de: kgersen le 19 janvier 2020 à 12:58:29

Oui impressionnant l'écart. On n'a pas de visibilité sur ce qui passe coté serveur (crosstalk notamment) du coup difficile de dire ou est la cause.

Coté serveur, la charge est stable :

Je suis intéressé pour connaître en détail l'optimisation que tu as fait pour MacOS , cela servira a d'autres utilisateurs.

vivien · « **Réponse #127 le:** 19 janvier 2020 à 13:52:15 »

Citation de: kgersen le 19 janvier 2020 à 12:58:29

ca fait beaucoup de lignes la je trouve. t'as configurer comment ton qdisc ?

C'est sans aucune modification.

Sur un Ubuntu 18.04 sans aucun tunning, ni logiciel installé à part Apache qui écoute sur le port 80 et 443, j'ai :

$ tc -s qdisc show dev eno1 qdisc mq 0: root Sent 3176 bytes 44 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 3176 bytes 44 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0 $ tc -s qdisc show dev eno2 qdisc mq 0: root Sent 3106 bytes 43 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 3106 bytes 43 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0 $ tc -s qdisc show dev enp2s0f0 qdisc mq 0: root Sent 8692466210818 bytes 1532106743 pkt (dropped 0, overlimits 0 requeues 136326) backlog 0b 0p requeues 136326 qdisc fq_codel 0: parent :8 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 1096363650344 bytes 735096903 pkt (dropped 0, overlimits 0 requeues 19701) backlog 0b 0p requeues 19701 maxpacket 68796 drop_overlimit 0 new_flow_count 26095 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 0: parent :7 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 1062000567154 bytes 711774005 pkt (dropped 0, overlimits 0 requeues 11640) backlog 0b 0p requeues 11640 maxpacket 68796 drop_overlimit 0 new_flow_count 5803 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 0: parent :6 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 1093329258305 bytes 732950108 pkt (dropped 0, overlimits 0 requeues 19320) backlog 0b 0p requeues 19320 maxpacket 68952 drop_overlimit 0 new_flow_count 19959 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 0: parent :5 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 1099425254672 bytes 737179948 pkt (dropped 0, overlimits 0 requeues 20945) backlog 0b 0p requeues 20945 maxpacket 69564 drop_overlimit 0 new_flow_count 22746 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 0: parent :4 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 1102078737978 bytes 738920622 pkt (dropped 0, overlimits 0 requeues 19732) backlog 0b 0p requeues 19732 maxpacket 73160 drop_overlimit 0 new_flow_count 20769 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 0: parent :3 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 1086794275891 bytes 728217355 pkt (dropped 0, overlimits 0 requeues 11444) backlog 0b 0p requeues 11444 maxpacket 68952 drop_overlimit 0 new_flow_count 5824 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 0: parent :2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 1077302264082 bytes 722130461 pkt (dropped 0, overlimits 0 requeues 16181) backlog 0b 0p requeues 16181 maxpacket 69564 drop_overlimit 0 new_flow_count 11720 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 1075172202392 bytes 720804637 pkt (dropped 0, overlimits 0 requeues 17363) backlog 0b 0p requeues 17363 maxpacket 68796 drop_overlimit 0 new_flow_count 14398 ecn_mark 0 new_flows_len 0 old_flows_len 0

Bref, pour moi c'est lié au pilote.

Les deux premières cartes sont :
04:00.0 Ethernet controller: Broadcom Inc. and subsidiaries NetXtreme BCM5720 Gigabit Ethernet PCIe Subsystem: Dell NetXtreme BCM5720 Gigabit Ethernet PCIe Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at 95a30000 (64-bit, prefetchable) [size=64K] Memory at 95a40000 (64-bit, prefetchable) [size=64K] Memory at 95a50000 (64-bit, prefetchable) [size=64K] Expansion ROM at 90200000 [disabled] [size=256K] Capabilities: [48] Power Management version 3 Capabilities: [50] Vital Product Data Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+ Capabilities: [a0] MSI-X: Enable+ Count=17 Masked- Capabilities: [ac] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [13c] Device Serial Number 00-00-50-9a-4c-6d-b2-22 Capabilities: [150] Power Budgeting <?> Capabilities: [160] Virtual Channel Kernel driver in use: tg3 Kernel modules: tg3

La dernière est :
02:00.0 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 01) Subsystem: Intel Corporation Ethernet 10G 2P X710 Adapter Flags: bus master, fast devsel, latency 0, IRQ 17 Memory at 92000000 (64-bit, prefetchable) [size=16M] Memory at 93008000 (64-bit, prefetchable) [size=32K] Expansion ROM at 90100000 [disabled] [size=512K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+ Capabilities: [70] MSI-X: Enable+ Count=129 Masked- Capabilities: [a0] Express Endpoint, MSI 00 Capabilities: [e0] Vital Product Data Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number e0-1d-1a-ff-ff-fe-fd-3c Capabilities: [150] Alternative Routing-ID Interpretation (ARI) Capabilities: [1a0] Transaction Processing Hints Capabilities: [1b0] Access Control Services Capabilities: [1d0] #19 Kernel driver in use: i40e Kernel modules: i40e

C'est du haut de gamme, le chips (connecté en PCIe 3) sait gérer le un dual-port 40 GbE, dual-port 25 GbE ou quad-port 10 GbE.

Edit, si il y a une chose que j'ai rajouté sur ce serveur qui n'est pas par défaut :

Code: [Sélectionner]

#!/bin/dash
# Limiter le nombre de sessions tcp par client (un client = une IPv4 ou un /64 en IPv6)
/sbin/iptables  -A INPUT -p tcp --syn -m connlimit --connlimit-above 600 -m limit --limit 30/hour --limit-burst 1 -j LOG --log-prefix="drop-c-"
/sbin/iptables  -A INPUT -p tcp --syn -m connlimit --connlimit-above 600 -j REJECT
/sbin/ip6tables -A INPUT -p tcp --syn -m connlimit --connlimit-above 600 --connlimit-mask 64 -m limit --limit 30/hour --limit-burst 1 -j LOG --log-prefix="drop-c-"
/sbin/ip6tables -A INPUT -p tcp --syn -m connlimit --connlimit-above 600 --connlimit-mask 64 -j REJECT

Breizh29 · « **Réponse #128 le:** 19 janvier 2020 à 14:34:32 »

Citation de: vivien le 19 janvier 2020 à 12:52:54

Tu fait comment pour générer ces graphiques avec une aussi grande résolution ? Je supposait que c'était Excel mais je ne vois pas de fonction d'export (et vu la résolution cela ne dois pas être une capture d'écran, sauf si tu es en 4k)

Oui, pour aller plus vite, ce sont bien des captures d'Excel, sur un écran 4K.
Je vais essayer de regrouper...

Citation de: vivien le 19 janvier 2020 à 12:52:54

Je note que en monothread tu as un meilleur débit en IPv6.

Effectivement, ça semble bien être le cas.

Breizh29 · « **Réponse #129 le:** 19 janvier 2020 à 14:55:17 »

Citation de: vivien le 19 janvier 2020 à 13:18:58

Je suis intéressé pour connaître en détail l'optimisation que tu as fait pour MacOS , cela servira a d'autres utilisateurs.

La voici.
Sachant qu'on n'est pour l'instant pas absolument certain que le changement provienne de ces modifications.

Comme je suis sous Catalina, la modification suivante est à opérer en mode recovery (boot en maintenant cmd + R, puis utiliser le terminal) :

Code: [Sélectionner]

nvram boot-args="ncl=262144"

Pour le reste, voici les valeurs de mon /etc/sysctl.conf :

Code: [Sélectionner]

kern.ipc.maxsockbuf=33554432
kern.ipc.somaxconn=2048

net.inet.tcp.sendspace=4194304
net.inet.tcp.recvspace=4194304
net.inet.tcp.win_scale_factor=8
net.inet.tcp.autorcvbufmax=33554432
net.inet.tcp.autosndbufmax=33554432

net.inet.tcp.slowstart_flightsize=20
net.inet.tcp.local_slowstart_flightsize=9

net.inet.tcp.mssdflt=1432
net.inet.tcp.v6mssdflt=1452

Note: c'est empirique, il y a sûrement encore pas mal de sources d'optimisation, et plein d'autres entrées à tuner.
Pour les valeurs de MSS, j'ai essayé de les déduire à partir des infos trouvées sur un autre fil de ce forum sur la MTU pour Free en zone FTTH 10G-EPON.

Par ailleurs, je suis preneur de conseils, car il s'agit de tests empiriques à partir de diverses lectures (que j'ai quand même essayé de comprendre, hein...).
Car bien que du métier, je ne suis spécialisé ni en réseau, ni en système.

vivien · « **Réponse #130 le:** 19 janvier 2020 à 15:14:49 »

Je conseillerais de ne pas toucher la MSS.

Comme expliqué dans le sujet Négociation MTU MSS: comment ça fonctionne ? si un équipement a beoin de le réduire la MSS, il va modifier à la volée dans les paquets [SYN] / [SYN-ACK] qui passent par lui.

Je ne connais pas le mac, mais pourquoi se mettre en mode recovery ?

Breizh29 · « **Réponse #131 le:** 19 janvier 2020 à 15:32:20 »

Citation de: vivien le 19 janvier 2020 à 15:14:49

Je ne connais pas le mac, mais pourquoi se mettre en mode recovery ?

Uniquement pour la modification des boot-args, depuis une des dernières versions de macOS, on est obligé de passer en mode recovery : même un sudo, qui suffisait avant, ne passe plus.
Augmenter le ncl (par défaut à 65536) est un passage obligatoire pour monter kern.ipc.maxsockbuf au-delà de 8 Mo.

Pour les autres, un sudo sysctl -w xxx=yyyy en mode classique suffit pour tester à chaud, avant de confirmer à chaque démarrage via sysctl.conf.