Что: 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. ------------------------------------------------------------------------ оставить комментарий: mailto:comment@blog.stargrave.org?subject=Re:%20%D0%92%D0%BA%D0%BB%D1%8E%D1%87%D0%B8%D0%BB%20FQ-CoDel.%20PIE%2C%20CAKE...%20%286588786a31b2cbec545beeecf1232338609ff9ce%29 ------------------------------------------------------------------------ Сгенерирован: SGBlog 0.34.0