Что: 6588786a31b2cbec545beeecf1232338609ff9ce
Когда: 2023-11-09 12:26:57+03:00
Темы: bsd netperf tip
Включил FQ-CoDel. PIE, CAKE...
https://www.youtube.com/watch?v=y5KPryOHwk8
https://www.bufferbloat.net/projects/
https://en.wikipedia.org/wiki/CoDel
https://datatracker.ietf.org/doc/html/rfc7567
https://datatracker.ietf.org/doc/html/rfc8290
https://habr.com/ru/articles/194274/
https://forum.netgate.com/topic/112527/playing-with-fq_codel-in-2-4
https://news.ycombinator.com/item?id=11516372
Traffic shaper я прежде использовал только для ограничения пропускной
способности того или иного трафика. Уже не помню как, но вышел на тему
связанную с AQM -- Active Queue Management. ECN (Explicit Congestion
Notification), который у меня включён, по идее работать должен только
при использовании AQM, ибо именно он должен оповещать о возникающих
задержках. Но AQM и без ECN должен быть полезен.
Увидел много упоминаний положительных о FQ-CoDel (FlowQueue-Controlled
Delay) алгоритме, который относительно недавно был добавлен в FreeBSD.
Пишут что без каких-либо настроек он резко улучшает usability и user
experience в сети при забитых каналах. Подтверждаю: при забитом на выход
BitTorrent-ом канале, ssh до VPS-ки теперь идёт как маслу, не замечаю
разницы между 10GbE соединением с шлюзом и забитым 100Mbps каналом в
Интернет.
Читаешь форумы, где говорят что невообразимая по полезности магия
происходит только включив (FQ-)CoDel -- и действительно визуально оно
ощутимо меняет поведение. iperf3 на 10GbE вроде бы не мешает, не замечаю
ощутимо большего использования CPU.
Хотя, как всегда, не совсем уверен
(f8e2e4dfc6870c4dad7e62be9bb02ae9dd73d180) в корректности настройки
firewall-а, но добавлял count log правила чтобы точно понимать попадает
ли под правило нужный мне трафик или нет.
Но для работы ECN нужна поддержка и от TCP. А у меня BBR
(e454488d86353680fdc8300a1567011572953e27), который не ECN-friendly.
BBRv2 дружелюбен к нему, но его нет в FreeBSD. На BitTorrent машине
временно включил CUBIC и статистика по ECN пошла:
# netstat -s | grep ECN
0 packets with ECN CE bit set
295108 packets with ECN ECT(0) bit set
177 packets with ECN ECT(1) bit set
3525 successful ECN handshakes
8 times ECN reduced the congestion window
Ещё я догадался проверить iperf3 свои 10GbE соединения после этого. И на
BBR с двумя параллельными соединениями он и до 5Gbps не вытягивает. А на
родном FreeBSD стэке (с CUBIC-ом вместо New Reno) спокойно все 10 выдаёт.
Конечно, один алгоритм для 10GbE LAN и загруженного 100Mbps Интернета не
может подойти одинаково хорошо, но пока от BBR откажусь.
IPv4 трафик, который в основном BitTorrent, который и забивает весь
исходящий канал, у меня идёт в gif-туннеле поверх IPv6 динамически
маршрутизируемых пакетов (a1251840ec6cc11b80519ae8a4f519f54c4358b9).
Чтобы ECN биты копировались из IPv4 заголовков в IPv6-ые, то надо сделать:
ifconfig gif_XXX link1
Но это только для внутренних туннелей годится. gif-ы с Hurricane
Electric и IP4Market (fb6dc9b409ae5051b610950dae0eaf4c70061437) не
поддерживают этой фишки, ибо она не по RFC.
А ещё бывают AQM-ы с красивым названиями типа:
PIE (Proportional Integral controller Enhanced) и
CAKE (Common Applications Kept Enhanced).
Первая ссылка -- видео поясняющее принципы AQM-а. Лектор здорово
подготовился ко всему этому представлению. Даже для RED алгоритма
использовал соответствующий цвет жидкости.
А в комментарии на HackerNews, пишут что в OpenBSD выпилили ECN, всё мол
плохо. Но это 2016-ый год. В его исходниках вижу, что и CoDel есть и ECN
вроде бы обрабатывается в TCP.
Сгенерирован: SGBlog 0.34.0