Les net.core.wmem_max et autres tcp_wmem  mais je crois que c'est déjà le cas sur ton serveur.

Iperf a déjà l'option -w pour ça qui utilise setsockopt() / SO_SNDBUF / SO_RCVBUF.
Le max peut être augmenté éventuellement si on veut dépasser les 16 Mo max sur le serveur de vivien.

J'ai ça actuellement :

Code: [Sélectionner]

# 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.

Ce qui est étonnant, c'est qu'il me semble que cela n'avait pas été modifié pour des test très haut débit dans les DROM avec un serveur sur Paris (donc forte latence) sur une connexion TCP.

Ces valeurs ne jouent que pour le tuning automatique des buffers, si l'outil de test utilise setsockopt() / SO_SNDBUF / SO_RCVBUF comme peut le faire iperf3 avec l'option -w, il passera outre ces valeurs.


Pour tcp_mem, c'est une valeur globale pour toutes les sockets, en pages de 4k, donc tu es déjà à 2 Go pour pressure et 3 Go pour max (en dessous de pressure il ne diminue pas les buffers en autotuning).


https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

tcp_rmem - vector of 3 INTEGERs: min, default, max
   min: Minimal size of receive buffer used by TCP sockets.
   It is guaranteed to each TCP socket, even under moderate memory pressure.
   Default: 4K

   default: initial size of receive buffer used by TCP sockets.
   This value overrides net.core.rmem_default used by other protocols.
   Default: 87380 bytes. This value results in window of 65535 with default setting of tcp_adv_win_scale and tcp_app_win:0 and a bit less for default tcp_app_win. See below about these variables.

   max: maximal size of receive buffer allowed for automatically
   selected receiver buffers for TCP socket. This value does not override net.core.rmem_max.  Calling setsockopt() with SO_RCVBUF disables automatic tuning of that socket's receive buffer size, in which case this value is ignored.
   Default: between 87380B and 6MB, depending on RAM size.

tcp_mem - vector of 3 INTEGERs: min, pressure, max
   min: below this number of pages TCP is not bothered about its
   memory appetite.

   pressure: when amount of memory allocated by TCP exceeds this number of pages, TCP moderates its memory consumption and enters memory pressure mode, which is exited when memory consumption falls under "min".

   max: number of pages allowed for queueing by all TCP sockets.

   Defaults are calculated at boot time from amount of available
   memory.

Et pourquoi ne pas tester l'algo CAIA (module cdg du noyau) ?

Mise à jour de ce matin 8h sur le graphe multithread + ajout d'une première version d'un graphe monothread.
Côté multi, pas de changement franchement notable du comportement.
Côté mono, c'est plus stable que ce que mes premiers tests me laissaient penser...

A 15h03, j'ai basculé initcwnd de 10 à 90, pour le trafic IPv6: On a donc IPv4 et IPv6 qui sont tous les deux en initcwnd 90

iface enp1s0f0 inet6 static
        address 2001:860:de01:1100::2
        netmask 64
        gateway 2001:860:de01:1100::1
post-up /sbin/ip -6 route change default via 2001:860:de01:1100::1 dev enp1s0f0 initcwnd 90
        accept_ra 0
        dns-nameservers 2001:860:b0ff:1::1 2001:860:b0ff:1::2


Demain matin je recommence les tests de différents algorithme de congestion TCP en gardant les optimisations actuelles.

- Aujourd'hui : Illinois, l'algorithme qui était souvent proposés pour des très haut débit (qdisc fq)
- Demain : Cubic l'algorithme par défaut de presque tous les Linux (qdisc fq)
- Après-demain : Cubic (test avec qdisc fq_codel)
- Les jours suivants : BBR sensé être l'algorithme miracle.