Comprendre tc qdisc et iperf

15

J'essaie de limiter la bande passante avec tcet de vérifier les résultats avec iperf. J'ai commencé comme ça:

# iperf -c 192.168.2.1
------------------------------------------------------------
Client connecting to 192.168.2.1, TCP port 5001
TCP window size: 23.5 KByte (default)
------------------------------------------------------------
[  3] local 192.168.2.7 port 35213 connected with 192.168.2.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   830 MBytes   696 Mbits/sec

Les deux instances sont directement connectées via Ethernet.

J'ai ensuite mis en place un htb qdiscavec une classe par défaut pour limiter la bande passante à 1 Mo / s:

# tc qdisc add dev bond0 root handle 1: htb default 12
# tc class add dev bond0 parent 1: classid 1:12 htb rate 1mbit

Mais je n'obtiens pas ce que j'attends:

# iperf -c 192.168.2.1
------------------------------------------------------------
Client connecting to 192.168.2.1, TCP port 5001
TCP window size: 23.5 KByte (default)
------------------------------------------------------------
[  3] local 192.168.2.7 port 35217 connected with 192.168.2.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-12.8 sec   768 KBytes   491 Kbits/sec

Si je double le débit, la bande passante mesurée ne change pas. Qu'est-ce que je rate? Pourquoi la bande passante mesurée ne correspond-elle pas au 1mbit du rateparamètre? Quels paramètres dois-je définir pour limiter la bande passante à un débit précis?

Cependant, la manpage indique que cela tbfdevrait être le qdiscchoix pour cette tâche:

Le Token Bucket Filter est adapté pour ralentir le trafic vers un débit configuré avec précision. S'adapte bien aux larges bandes passantes.

tbfnécessite des paramètres rate, burstet ( limit| latency). J'ai donc essayé ce qui suit sans comprendre comment burstet ( limit| latency) affectent la bande passante disponible:

# tc qdisc add dev bond0 root tbf rate 1mbit limit 10k burst 10k

Cela m'a donné une bande passante mesurée de 113 Kbits / sec. Jouer avec ces paramètres n'a pas beaucoup changé jusqu'à ce que je remarque que l'ajout d'une valeur pour les mtuchoses change radicalement:

# tc qdisc add dev bond0 root tbf rate 1mbit limit 10k burst 10k mtu 5000

a donné lieu à une bande passante mesurée de 1,00 Mbits / s.

Quels paramètres dois-je définir pour limiter la bande passante à un débit donné exact?

Dois-je utiliser la discipline htbou la tbffile d'attente pour cela?

MODIFIER :

Sur la base de ces ressources, j'ai fait quelques tests:

J'ai essayé les configurations suivantes.

Sur une machine physique

/etc/network/interfaces:

auto lo
iface lo inet loopback

auto br0
iface br0 inet dhcp
bridge_ports eth0

Mesure avec iperf:

# tc qdisc add dev eth0 root handle 1: htb default 12
# tc class add dev eth0 parent 1: classid 1:12 htb rate 1mbit
# iperf -c 192.168.2.1
------------------------------------------------------------
Client connecting to 192.168.2.1, TCP port 5001
TCP window size: 23.5 KByte (default)
------------------------------------------------------------
[  3] local 192.168.2.4 port 51804 connected with 192.168.2.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-11.9 sec  1.62 MBytes  1.14 Mbits/sec

Alors que le iperfserveur a calculé une bande passante différente:

[  4] local 192.168.2.1 port 5001 connected with 192.168.2.4 port 51804
[  4]  0.0-13.7 sec  1.62 MBytes   993 Kbits/sec

Sur une machine virtuelle sans liaison

/etc/network/interfaces:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

Mesure avec iperf:

# tc qdisc add dev eth0 root handle 1: htb default 12
# tc class add dev eth0 parent 1: classid 1:12 htb rate 1mbit
# iperf -c 192.168.2.1
------------------------------------------------------------
Client connecting to 192.168.2.1, TCP port 5001
TCP window size: 23.5 KByte (default)
------------------------------------------------------------
[  3] local 192.168.2.7 port 34347 connected with 192.168.2.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-11.3 sec  1.62 MBytes  1.21 Mbits/sec

Alors que le iperfserveur a calculé une bande passante différente:

[  4] local 192.168.2.1 port 5001 connected with 192.168.2.7 port 34347
[  4]  0.0-14.0 sec  1.62 MBytes   972 Kbits/sec

Sur une machine virtuelle avec liaison (tc configuré sur eth0)

/etc/network/interfaces:

auto lo
iface lo inet loopback

auto eth0
allow-bond0 eth0
iface eth0 inet manual
    bond-master bond0
    bond-primary eth0 eth1

auto eth1
allow-bond0 eth1
iface eth1 inet manual
    bond-master bond0
    bond-primary eth0 eth1

auto bond0
iface bond0 inet dhcp
    bond-slaves none
    bond-mode 1
#    bond-arp-interval 250
#    bond-arp-ip-target 192.168.2.1
#    bond-arp-validate 3

Mesure avec iperf:

# tc qdisc add dev eth0 root handle 1: htb default 12
# tc class add dev eth0 parent 1: classid 1:12 htb rate 1mbit
# iperf -c 192.168.2.1
------------------------------------------------------------
Client connecting to 192.168.2.1, TCP port 5001
TCP window size: 23.5 KByte (default)
------------------------------------------------------------
[  3] local 192.168.2.9 port 49054 connected with 192.168.2.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-11.9 sec  1.62 MBytes  1.14 Mbits/sec

Alors que le iperfserveur a calculé une bande passante différente:

[  4] local 192.168.2.1 port 5001 connected with 192.168.2.9 port 49054
[  4]  0.0-14.0 sec  1.62 MBytes   972 Kbits/sec

Sur une machine virtuelle avec liaison (tc configuré sur bond0)

/etc/network/interfaces:

auto lo
iface lo inet loopback

auto eth0
allow-bond0 eth0
iface eth0 inet manual
    bond-master bond0
    bond-primary eth0 eth1

auto eth1
allow-bond0 eth1
iface eth1 inet manual
    bond-master bond0
    bond-primary eth0 eth1

auto bond0
iface bond0 inet dhcp
    bond-slaves none
    bond-mode 1
#    bond-arp-interval 250
#    bond-arp-ip-target 192.168.2.1
#    bond-arp-validate 3

Mesure avec iperf:

# tc qdisc add dev bond0 root handle 1: htb default 12
# tc class add dev bond0 parent 1: classid 1:12 htb rate 1mbit
# iperf -c 192.168.2.1
------------------------------------------------------------
Client connecting to 192.168.2.1, TCP port 5001
TCP window size: 23.5 KByte (default)
------------------------------------------------------------
[  3] local 192.168.2.9 port 49055 connected with 192.168.2.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-13.3 sec   768 KBytes   475 Kbits/sec

Alors que le iperfserveur a calculé une bande passante différente:

[  4] local 192.168.2.1 port 5001 connected with 192.168.2.9 port 49055
[  4]  0.0-14.1 sec   768 KBytes   446 Kbits/sec

Le résultat ne change pas si je retire eth1(l'interface passive) du lien.

Conclusion

Le contrôle du trafic sur une interface de liaison ne fonctionne pas, ou du moins pas comme prévu. Je vais devoir enquêter davantage.

Comme solution de contournement, on pourrait ajouter les disciplines de mise en file d'attente directement aux interfaces appartenant à la liaison.

tc Matías E. Fernández
la source
Curieusement, cela semble avoir fonctionné pour ce type: blog.tinola.com/?e=22
Matías E. Fernández
1
Je pense qu'avec htb, vous devez utiliser tc filterpour mettre les paquets en classes. Vous devrez peut-être également modifier certains des paramètres htb (réglez-le comme tbf). Je suggère de se pencher sur tcngce qui est un frontal pour tc. (Ce sont des pointeurs rapides ...)
derobert
Je n'ai vu aucun filtre dans votre message. Quelles commandes utilisez-vous pour faire correspondre le trafic afin qu'il puisse être limité en débit?

Réponses:

2

Lorsque vous n'êtes pas sûr du fonctionnement de tc, vous pouvez toujours surveiller tc et voir comment les paquets s'écoulent? Vous pouvez utiliser mon script pour surveiller tc et devez l'exécuter dans un terminal avec des privilèges élevés. Vous pouvez changer wlan0 en une autre interface et vous avez également besoin de grep et awk:

      #!/bin/sh
      INTERVAL=15
      while sleep $INTERVAL
      do
             /usr/sbin/tc -s -d class show dev wlan0

             uptime
             more /proc/meminfo | grep MemFree | grep -v grep
             echo cache-name num-active-objs total-objs obj-size
             SKBUFF=`more /proc/slabinfo | grep skbuff | grep -v grep | awk 
             '{print $2} {print $3} {print $4}'`

             echo skbuff_head_cache: $SKBUFF
      done
Gigamegs
la source
0

Essayez d'augmenter les valeurs burst/ limit. Les algorithmes du seau à jetons évoluent bien, mais ont un rapport précision / vitesse limité.

La précision est obtenue en utilisant un petit seau, la vitesse en augmentant la taille des jetons. Les gros jetons signifient que la vitesse à laquelle ils sont réapprovisionnés est diminuée (jetons par seconde = octets par seconde / octets par jeton).

Le rateparamètre donne le taux moyen à ne pas dépasser, les paramètres burstou limitdonnent la taille de la fenêtre de moyenne. Étant donné que l'envoi d'un paquet à la vitesse de la ligne dépasse le débit défini pendant le temps où le paquet est transféré, la fenêtre de calcul de la moyenne doit être au moins suffisamment grande pour que l'envoi d'un seul paquet ne pousse pas la fenêtre entière au-delà de la limite; si plus de paquets tiennent dans la fenêtre, l'algorithme aura une meilleure chance d'atteindre la cible exactement.

Simon Richter
la source
0

exécutez ceci avant d'ajouter une discipline de file d'attente sur l'interface de liaison (bond0 dans ce cas)

ipconfig bond0 txqueuelen 1000

cela ne fonctionne pas car le périphérique virtuel logiciel comme l'interface de liaison n'a pas de file d'attente par défaut.

Ventilateur
la source
0

Étant donné que les bondappareils n'ont pas de file d'attente définie, la définition de la qdisctaille résout explicitement le problème pour moi.

Voici un exemple de feuille qdiscà utiliser sous la HTBstructure: tc qdisc add dev $dev parent $parent handle $handle pfifo limit 1000

SagiLow
la source