ipfw traffic shaping

[Цап-Царапыч]

Здравствуйте всем!

имеется FreeBSD 13.3

Столкнулся с такой проблемой при нарезке скорости, что скорость больше 200Mbit/s уже режется не так точно, и если выставить например 600Mbit/s то скорость не поднимается с примерно 440Mbit/s до указанных 600Mbit/s
Хорошо скорость нарезается при 100Mbit/s

Подскажите, куда копать, в чем может быть причина такого "поведения" ?

вот ipfw правило которое я использую.

#!/bin/sh

set -ex

fw="/sbin/ipfw -q"
if ! kldstat -q -m dummynet; then
        kldload dummynet
fi


if_ext=bce0
if_int=bce1

$fw -f flush
$fw -f pipe flush
$fw -f queue flush
$fw -f nat flush


bwu=650Mbit/s
bwd=600Mbit/s

$fw pipe 1 config bw $bwu
$fw pipe 2 config bw $bwd

$fw queue 1 config pipe 1 mask src-ip 0xffffffff
$fw queue 2 config pipe 2 mask dst-ip 0xffffffff

$fw add queue 1 ip from any to any xmit $if_int out
$fw add queue 2 ip from any to any recv $if_int in

${fw} nat 1 config log if $if_ext reset same_ports unreg_only deny_in reset
${fw} 00080 add nat 1 ip from 10.10.0.0/16 to any out via $if_ext
${fw} 00081 add nat 1 ip from any to $(ifconfig $if_ext|grep inet|awk '{print $2}') in via $if_ext

$fw add 3000 allow ip from any to any

 

Edited March 27, 2024 by Цап-Царапыч

[Ivan_83]

Посмотрите мануал на dummynet. Мне кажется там влияние HZ (kern.hz) есть.

[ixi]

В 27.03.2024 в 10:51, Цап-Царапыч сказал:

Подскажите, куда копать, в чем может быть причина такого "поведения" ?

Попробуйте увеличить queue, стандартного значения для больших скоростей маловато. + бёрсты иногда полезно

Edited April 1, 2024 by ixi

[zyxman]

Quote

Мне кажется там влияние HZ (kern.hz) есть

НЕ кажется. Там гарантированно частота клока влияет. Рекомендуют ставить 10КГц, я ставлю 1000Гц и для моего PPS (SOHO) этого хватает, реально ОЧЕНЬ точно нарезает.

Дефолтовые там вообще 100Гц, что конечно совершенно недостаточно и режет ужасно грубо и задержку аж до 10мс еще может легко добавлять просто отфонарно, конечно до 100% теоритического максимума интерфейс не разгонится.

[Ivan_83]

3 hours ago, zyxman said:

Дефолтовые там вообще 100Гц, что конечно совершенно недостаточно

Вовсе нет.

 

Quote

# CLOCK OPTIONS

# The granularity of operation is controlled by the kernel option HZ (default
# frequency of 1000 Hz or a period 1ms between calls). Virtual machine guests
# use a value of 100. Lower values may lower overhead at the expense of accuracy
# of scheduling, though the adaptive tick code reduces that overhead.

options     HZ=100

 

# sysctl kern.hz
kern.hz: 1000

 

# grep -rsp "HZ" /usr/src/sys/ | grep 'options'
/usr/src/sys/arm/conf/std.armv6:options 	HZ=1000
/usr/src/sys/arm/conf/std.armv7:options 	HZ=1000
/usr/src/sys/conf/options:HZ		opt_param.h
/usr/src/sys/dev/e1000/README:  options HZ=1000
/usr/src/sys/riscv/conf/QEMU:options 	HZ=100

[zyxman]

Quote

Вовсе нет.

Значит уже поменяли. Хорошо. Раньше было 100. Ну короче, надо попробовать сделать больше, и я бы начал с того что везде поставил 5000 и посмотрел что изменится.

 

И еще, я бы не гнался за большими буферами, вот уменьшал бы их пока не начнет что-то происходить, возможно ядро будет ругаться или тормоза начнутся (лоад подскочит), отогда значит близко к идеалу пришли.

[Azamat]

Нужно читать в направлении влияния размеров очередей queue и тонкой настройки дропов gred

 

Мы вот так выставляем 110мбит/с
bw 112640Kbit/s queue 2048 gred 0.002/572/1700/0.1

 

там будет еще, с чем побороться - но это уже сами.