> Спасибо ещё раз.
> Читаю мануал ipfw и dummynet и складывается понимание, что queue используется именно
> как некий буффер чтения, при заполненной полосе bw,
> при переполнении которого пакеты просто отбрасываются, если не успевают проходить в bw,
> НО не как буффер для накопления перед отправкой,
> который опустошается (в канал с учётом bw) при заполнении или по delay. Это КОРЗИНА, которая заполняется пришедшими пакетами со скоростью ограниченной bw, то есть если будет приходить больше, будут отбрасываться сразу.
Далее, если суммарный размер пакетов находящихся в корзине с новым больше отконфигуренного размера, или если в корзине максимальное количество пакетов, новый пакет НЕ добавляется а отбрасывается.
Далее, если пакет таки попал в корзину, включается таймер и он там сидит до тех пор пока не закончится delay, как закончится delay отправляется дальше по ipfw и удаляется из корзины (освобождает место в корзине).
Проверка производится не в абстрактные моменты времени, а строго по тикам таймера, который по умолчанию в фре 6 был 50Гц, сейчас не знаю сколько, но на современных машинках можно спокойно ставить 1000Гц, это не очень высокая точность но техника переваривает не напрягаясь.
Да, за давностию лет я могу перепутать некоторые нюансы, типа в каком конце находится ограничитель скорости и тп, но логика по-моему точно такая.
То есть, если вы сделаете очень маленькие буфера, при очень большой скорости будет маленькая задержка В БУФЕРАХ, но часть пакетов будет отбрасываться; если сделать очень большие буфера, будет задержка большая.
Обычно есть некоторый оптимум задержки и потерь пакетов в таких шейперах, его нужно подбирать экспериментальным путем.
>> 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 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
> Или я где-то ошибаюсь?
perl -e 'print "".(1300000/8/64)."\n"'
2539.0625
perl -e 'print "".(1300000/8/1500)."\n"'
108.333333333333
Как говорится в классике - удачной охоты!
Вариант для распечатки
(?), 04-Апр-24, 02:00 
