- Агрегация (объединение мелких пакетов) при туннелировании,
 Pahanivo пробегал, 00:12 , 29-Мрт-24 (1)
- Агрегация (объединение мелких пакетов) при туннелировании, Олег Бартунов, 01:31 , 29-Мрт-24 (2)
>на забитом каналеВ том-то и дело, по пропускной способности он не забит и на 10% >а я так понимаю у тебя что-то реалтаймовское там ходит Нет, задержки до 5000мс меня вполне устроят.
По сути мне нужен тот же алгоритм Нейгла, просто менее ориентированный на на реалтайм.
- Агрегация (объединение мелких пакетов) при туннелировании, Аноним, 00:58 , 01-Апр-24 (4)
- Агрегация (объединение мелких пакетов) при туннелировании, ACCA, 22:22 , 01-Апр-24 (5)
- Агрегация (объединение мелких пакетов) при туннелировании, zyxman, 07:57 , 02-Апр-24 (6) +1
- Агрегация (объединение мелких пакетов) при туннелировании, Олег Бартунов, 09:58 , 03-Апр-24 (7)
>> Есть ли какие-либо варианты аггрегации мелких пакетов по достижению заданного размера или
>> по таймауту?
> Вообще буквально так работает FreeBSD ipfw pipe, там буквально есть корзина, которая
> заполняется пакетами и освобождается, либо когда пакет задержан на сколько заказано,
> либо когда корзина переполнилась.Это уже интересно, спасибо!
Читаю handbook и мануал по ipwf и не нахожу ничего похожего на корзину, только delay применяемый для каждого отдельного пакета. Можешь ткнуть конкретно или привести некоторые правила от которых можно оттолкнуться?
А то чувствую себя хлебушком в freebsd, после 15 лет на debian. Я правильно понимаю, что чтоб с обратной стороны не получать отдельные пакеты ответов, то надо с обоих сторон [freebsd>openvp] <канал> [openvpn<freebsd]
- Агрегация (объединение мелких пакетов) при туннелировании, zyxman, 02:00 , 04-Апр-24 (8) +1
- Агрегация (объединение мелких пакетов) при туннелировании, Олег Бартунов, 22:03 , 06-Апр-24 (10)
Спасибо ещё раз.
Читаю мануал ipfw и dummynet и складывается понимание, что queue используется именно как некий буффер чтения, при заполненной полосе bw,
при переполнении которого пакеты просто отбрасываются, если не успевают проходить в bw, НО не как буффер для накопления перед отправкой,
который опустошается (в канал с учётом bw) при заполнении или по delay.
Или delay здесь не нужен так как он будет просто тормозить все пакеты и не связан с queue?> The queue option sets the maximum amount of excess data (in packets or KBytes) that will be accepted before additional packets are refused. Собственно, как именно это будет интерпретироваться, по сути мне только это и надо,
10.1.1.111 - tun0 в клиенте локальной freebsd, 10.1.1.1 - tun0 - внешнего сервера, тоже на freebsd. ipfw add pipe 1 ip from 10.1.1.111/32 to 10.1.1.1/32 out
ipfw pipe 1 config bw 10Mbit/s queue 4KBytes delay 24ms Если я правильно понял, то "queue 4KBytes delay 24ms" это (4096×8)×(1000÷24) = канал 1.3Мбит/с, что существенно ниже bw 10Mbit/s Ещё вопрос, если это всё таки накопление перед отправкой, то имеет ли смысл сделать queue кратно mtu (mtu*2|4|8), и поиграть с разными mtu в openvpn? PS, канал 1.3Мбит/с - это 21k pps для пакетов по 64 байта или 10k для пакетов 128 байт, либо примерно 910 pps для 1500 Или я где-то ошибаюсь?
- Агрегация (объединение мелких пакетов) при туннелировании, zyxman, 01:32 , 07-Апр-24 (11)
- Агрегация (объединение мелких пакетов) при туннелировании, Олег Бартунов, 14:52 , 07-Апр-24 (12)
Локальная kvm freebsd, openvpn
ipfw add 10 pipe 1 udp from 10.11.9.21 to 10.11.9.1 out
ipfw pipe 1 config bw 2Mbit/s queue 4KBytes # лимит выше 1Мбит (-b 1M), условно, без лимита
iperf3 -u -c 10.11.9.1 -b 1M -t -2 -l 64[ ID] Interval Transfer Bitrate Total Datagrams
[ 5] 0.00-1.00 sec 122 KBytes 999 Kbits/sec 1952
[ 5] 1.00-2.00 sec 122 KBytes 1000 Kbits/sec 1953
[ 5] 2.00-3.00 sec 122 KBytes 1000 Kbits/sec 1953
[ 5] 3.00-4.00 sec 122 KBytes 1000 Kbits/sec 1953
[ 5] 4.00-5.00 sec 122 KBytes 1000 Kbits/sec 1953
[ 5] 5.00-6.00 sec 122 KBytes 1000 Kbits/sec 1953 Хост debian, проверял pps как для vnet30, так и для wlan0
Количество пакетов в секунду одинаковое tx 1 rx 1966 / pps on vnet30
tx 1 rx 1962 / pps on vnet30
tx 1 rx 1955 / pps on vnet30
tx 1 rx 1962 / pps on vnet30
tx 1 rx 1961 / pps on vnet30 tx 1958 rx 2 / pps on wlan0
tx 1961 rx 2 / pps on wlan0
tx 1955 rx 3 / pps on wlan0
tx 1964 rx 2 / pps on wlan0
tx 1954 rx 2 / pps on wlan0 Дополнительно, на хосте смотрел iptraf-ng на этих интерфейсах, и там всё те же пакеты, 58-112-192 байт, с тем же pps С другой стороны, freebsd, openvpn
iperf3 -s [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 107 KBytes 874 Kbits/sec 1.316 ms 0/1708 (0%)
[ 5] 1.00-2.00 sec 122 KBytes 1.00 Mbits/sec 1.040 ms 0/1960 (0%)
[ 5] 2.00-3.00 sec 120 KBytes 981 Kbits/sec 0.660 ms 0/1918 (0%)
[ 5] 3.00-4.00 sec 124 KBytes 1.02 Mbits/sec 0.624 ms 0/1985 (0%)
[ 5] 4.00-5.00 sec 122 KBytes 998 Kbits/sec 0.648 ms 0/1950 (0%)
[ 5] 5.00-6.00 sec 122 KBytes 997 Kbits/sec 0.614 ms 0/1948 (0%)
[ 5] 6.00-7.00 sec 122 KBytes 1.00 Mbits/sec 0.690 ms 0/1954 (0%)
[ 5] 7.00-8.00 sec 124 KBytes 1.02 Mbits/sec 0.642 ms 0/1983 (0%)
[ 5] 8.00-9.00 sec 121 KBytes 991 Kbits/sec 0.835 ms 0/1937 (0%)
[ 5] 9.00-10.00 sec 121 KBytes 994 Kbits/sec 1.394 ms 0/1942 (0%)
[ 5] 10.00-11.00 sec 124 KBytes 1.02 Mbits/sec 0.666 ms 0/1984 (0%)
[ 5] 11.00-12.00 sec 122 KBytes 998 Kbits/sec 0.614 ms 0/1949 (0%)
[ 5] 11.00-12.00 sec 122 KBytes 998 Kbits/sec 0.614 ms 0/1949 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[SUM] 0.0-12.0 sec 31 datagrams received out-of-order
[ 5] 0.00-12.00 sec 1.53 MBytes 1.07 Mbits/sec 0.705 ms 0/25053 (0%) receiver Таким образом, с лимитом (bw 2Mbit/s) выше указанного в iperf (-b 1M) 1952 пакета в секунду проходят без потерь, и без объединения.
Локальная freebsd:
ipfw pipe 1 delete
ipfw pipe 1 config bw 512Kbit/s queue 24KBytes delay 24ms
iperf3 -u -c 10.11.9.1 -b 1M -t -2 -l 64 [ ID] Interval Transfer Bitrate Total Datagrams
[ 5] 0.00-1.00 sec 122 KBytes 999 Kbits/sec 1952
[ 5] 1.00-2.00 sec 122 KBytes 1000 Kbits/sec 1953
[ 5] 2.00-3.00 sec 122 KBytes 1000 Kbits/sec 1953
С другой стороны, ожидаемо:
[ 5] 17.02-18.00 sec 54.4 KBytes 457 Kbits/sec 2.635 ms 1571/2442 (64%)
[ 5] 18.00-19.00 sec 43.8 KBytes 358 Kbits/sec 1.519 ms 1271/1971 (64%)
[ 5] 19.00-20.00 sec 43.5 KBytes 356 Kbits/sec 2.505 ms 1257/1953 (64%)
[ 5] 19.00-20.00 sec 43.5 KBytes 356 Kbits/sec 2.505 ms 1257/1953 (64%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-20.00 sec 882 KBytes 361 Kbits/sec 2.566 ms 24773/38887 (64%) receiver
Локальный хост:
tx 1 rx 697 / pps on vnet30
tx 1 rx 703 / pps on vnet30
tx 1 rx 703 / pps on vnet30 То есть, я просто получю шейпер.
При разных вариантах очереди, таймаута, полосы, получается шейпер.
Всё работает логично и правильно, и тут не должно быть никаких объединений нескольких мелких пакетов в один mtu. Так у меня изначальный вопрос был, есть ли возможность объединить в канале, например, openvpn мелкие пакеты, снизив внешний pps?
|
Версия для распечатки
Агрегация (объединение мелких пакетов) при туннелировании, 
