Die Verkehrssteuerung in Linux-Namespaces führt zu einer sehr geringen Bandbreite

422
dastan

Ich erwarte, den Ingress-Verkehr veth0im Namespace zu begrenzen ns0.

Was ich mache, gibt die folgenden Befehle aus:

# create netns ip netns add ns0  # create veth pair ip link add dev veth0 type veth peer name veth1 ip link set dev veth0 netns ns0 # set them UP ... ip netns exec ns0 ip addr add ... # add ipv4 addr to veth0  # link veth1 to br0 which is a linux bridge connecting physical interface # bond1 where testing traffic comes from. ip link set dev veth1 master br0  # setup traffic control rules ip netns exec ns0 tc qdisc add dev veth0 handle ffff: ingress ip netns exec ns0 tc filter add dev veth0 parent ffff: protocol ip prio 1 u32 match ip src 0.0.0.0/0 police rate 100mbit burst 1mbit drop flowid :1 

Nach all dem erwarte ich ein iperf-Ergebnis von etwa 100 Mbps, aber eigentlich bekomme ich nur eine Bandbreite von 14 Mbps.

Gibt es eine implizite Einschränkung für tc, die mir nicht bekannt ist?

2
FWIW, ich muss noch Liniengeschwindigkeiten bekommen, wenn ich tc-Shaping mit vernünftigen Grenzen hinzufüge. Um Leitungsgeschwindigkeiten zu erhalten, muss ich die maximale Geschwindigkeit auf etwa das 10-fache meiner tatsächlichen Leitungsgeschwindigkeiten einstellen. Ich habe dieses Problem bei mehreren Algorithmen festgestellt. Die CPU steht kurz vor dem Einsatz, Max Down ist bei 25 MByte aufgeführt, liegt aber eher bei 31 MByte, während der Upload bei 10 MByte liegt. Wenn ich Verkehrskontrolle mache, bin ich glücklich, 6-7 nach oben zu bringen und 15-20 MB nach unten zu bringen (ich gebe die schnelleren gemessenen Geschwindigkeiten ein, um mit BTW zu beginnen. WENN ich etwas finde, werde ich versuchen, hier zu posten ... Astara vor 5 Jahren 0

0 Antworten auf die Frage