The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Доступна платформа оптимизации трафика LibreQoS 1.4"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от opennews (?), 30-Ноя-23, 13:33 
Опубликован выпуск платформы LibreQoS 1.4, предназначенной для организации справедливого распределения имеющейся полосы пропускания между пользователями и снижения негативных эффектов, возникающих из-за промежуточной буферизации пакетов (Bufferbloat) сетевым оборудованием. Платформа может использоваться провайдерами или администраторами частных сетей для оптимизации потоков трафика, поддержания задержек на минимальном уровне и распределения полосы пропускания с учётом приоритетов. Код проекта написан на языках Си, Python и Rust, и распространяется под лицензией GPLv2. Проект развивается под руководством Дэйва Тахта (Dave Taht), сооснователя проекта Bufferbloat, создателя дистрибутива CeroWrt и автора многочисленных RFC, связанных с обработкой сетевых очередей...

Подробнее: https://www.opennet.me/opennews/art.shtml?num=60202

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +2 +/
Сообщение от 11111001010 (?), 30-Ноя-23, 13:33 
Уже версия 1.4, а я об этой платформе впервые в жизни слышу. Почему о ней мало говорят?
Ответить | Правка | Наверх | Cообщить модератору

3. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +1 +/
Сообщение от Антон 19887234 (?), 30-Ноя-23, 14:13 
По той же причине, почему операторы в свое время отказались от DPI для ограничения торрентов: магистральные каналы, магистральное оборудование DWDM и пакетной сети стали дешевле, чем DPI.
11 Гбит/с на сервер - это раз в 7 меньше, чем граница экономической целесообразности использования этого решения.
Ответить | Правка | Наверх | Cообщить модератору

4. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от WEemail (?), 30-Ноя-23, 14:50 
Это в каком у вас манямирке операторы отказались от DPI?
Первейшая маркетинговая потребность ограничения полосы для оператора - это пакетирование услуг, потом идёт приоритизация, далее это защита от невалидного трафика и последнее это фильтрация. Плюс есть сопутствующие услуги, типа анализ протоколов и сервисов, что тоже любит маркетинг.

А не слышали вы о таких проектах, потому что колхоз-телекомов всё меньше, и они на б.у. оборудовании сидят.

Ответить | Правка | Наверх | Cообщить модератору

10. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +2 +/
Сообщение от Антон 19887234 (?), 30-Ноя-23, 16:54 
В том мирке, где живут операторчики типа 3216, 12389, 20485. Имя Ибрагим... тьфу ты. Номерки эти вам о чем-то говорят?
Ответить | Правка | Наверх | Cообщить модератору
Часть нити удалена модератором

14. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от Антон 19887234 (?), 30-Ноя-23, 18:26 
Чтобы резать полосу DPI не нужОн, дорогуша! Сейчас любое PS Core искаропки по возможностям уделает любой шпдшный BRAS, не считая поделки красноглазиков. Приоритезация важного, деприоритезация тяжелого и т.п. - это все без DPI накручивается. А зачем? А чтобы не убить радиочастотный спектр говнотрафиком. Всё.

А что же ШПД? А на ШПД такой проблемы нет, там провод. Я уже писал выше, что ставить любую железку "в разрыв" и что-то там резать не выгодно, дешевле расширить емкость под этот трафик.

Уссываюсь, друзья мои, когда читают маркетинговые писульки всяких отечественных "производителей" потипа СКАТ или РДП.РУ, которые все еще помнят про Торренты! А тех уже менее 5%, даже в самых богом забытых регионах, где, казалось бы, скорости не должны позволять смотреть онлайн.

И да, ты сделала ошибку, МегаФно в списке замени на полосатых, и получишь большую магистральную тройку РФ)))

Ответить | Правка | Наверх | Cообщить модератору

15. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от Антон 19887234 (?), 30-Ноя-23, 18:30 
А про b2o что же не вспомнил? Там режут еще смешнее - полисёрами на интерфейсах! А как же DPI, спросишь? А никак полисёр режет идеально 1,2,3,5 гиг, 10,15,20, 80, 100 и более гиг)
Ответить | Правка | Наверх | Cообщить модератору

16. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от Аноним (16), 30-Ноя-23, 18:33 
Ещё бы не говорили! Обычно эти первые в списке подозреваемых, вместе с 4812, 4134 и тому подобными, в случае атак разных скаммеров, скриптикиддисов и прочей шелупони. Особенно клиенты из финтеха их «любят»: просят заблэкхолить ещё до поднятия сессии.
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

36. "Доступна платформа оптимизации трафика LibreQoS 1.4"  –2 +/
Сообщение от Антон 19887234 (?), 01-Дек-23, 09:25 
Китайцы умеют играть в монополию, а наши долб0ебы нет.
Поэтому у них китайский IP-транзит стоит $100 за Мбит/с, а у нас - $0.3.
Три компании договорились и держат планку, не отдают себя задешево: CT, CU, CM.
В РФ три компании не смогли договорится, и просадили стоимость донельзя: ВК, РТ, ТТК.
Кто-то выиграл от этого? Да, антимонопольщики!
Ответить | Правка | Наверх | Cообщить модератору

46. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +2 +/
Сообщение от Аноним (16), 01-Дек-23, 20:31 
Кастомеры выиграли и все операторы, которые в обход той монополии могут трафик в/из APAC доставить. А учитывая кто с какой стороны забора оказался со всеми этими геополитическими движениями, то похоже, что скоро транзит китай будет продавать только в рф, а рф — только в китай. Такой вот чебуркванмён получается.
Ответить | Правка | Наверх | Cообщить модератору

50. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от torvn77 (ok), 06-Дек-23, 18:23 
Ты забыл Турцию и Иран, да и другие страны из Персидского Залива и Африки скорее всего тоже примкнут.
Ответить | Правка | Наверх | Cообщить модератору

30. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +1 +/
Сообщение от 1 (??), 30-Ноя-23, 23:28 
Вы шутите? У этих операторов DPI на транзитном трафике. Никогда не видели заглушку о заблокированном в РФ сайте от Билайна, при попытке, например, зайти на хост в Казахстане из Европы?
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

33. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от Антон 19887234 (?), 01-Дек-23, 09:18 
Разуй глаза и почитай о чем речь. Про блокировки речи нет в принципе, и DPI там крайне ограниченный, к ограничению скорости или перемаркировке QoS отношения не имеющий.
Ответить | Правка | Наверх | Cообщить модератору

5. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +2 +/
Сообщение от Аноним (5), 30-Ноя-23, 14:57 
Но для локалок малых и средних бизнесов может быть актально.
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

27. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от нах. (?), 30-Ноя-23, 21:27 
точнее для малых и очень малых. Где не магистральное подключение а сопли из стены и на них wifi роутер на всю эту подвальную лавку. Вот у них и "заикается голосовой чятик если рядом качать видио в 4k"

А у средних все же уже принято иметь свою AS, нормальные подключения к нескольким кормушкам и им тоже проще попросить поднять тариф на следующую ступеньку и не париться (а эта поделка у них попросту лопнет)

Ответить | Правка | Наверх | Cообщить модератору

35. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от Антон 19887234 (?), 01-Дек-23, 09:21 
Ребятушки! Малые и очень малые - это компания из 1-2 человек, где директор=бухгалтер=монтажник=админ. Поставил микротиков кое-как настроенных и собирает копеечку. Никаких проблем с чятиками там не решается, т.к. уровень понимания техники там житейский: пакеты идут как говно в канализации, чтобы устранить узкое место (засор) нужно побольше открыть вкладок в браузере, авось продавит!
Ответить | Правка | Наверх | Cообщить модератору

38. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от нах. (?), 01-Дек-23, 11:56 
Ну да. Именно для них оно и будет рабочим решением. Ну или для продавана решениев таким вот - как наш анонимный друг и заподозрил, наткнувшись на характерную табличку.

> Никаких проблем с чятиками там не решается, т.к. уровень понимания техники там житейский

кто побогаче - вызывает канализатора, тот ему узкое место и устраняет как умеет. Ну вот например таким образом.

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

Ответить | Правка | Наверх | Cообщить модератору

17. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +2 +/
Сообщение от pofigist (?), 30-Ноя-23, 19:16 
Потому что QoS принято настраивать на коммутаторах, а это поделие и 1mpps прокачать не сможет.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

34. "Доступна платформа оптимизации трафика LibreQoS 1.4"  –2 +/
Сообщение от Антон 19887234 (?), 01-Дек-23, 09:19 
QoS принято настраивать везде, где есть компетентные сотрудники.
Если сотрудник (или это Вы и есть) говорит, что у нас нет перегрузок и QoS не нужно настраивать - то выдайте ему трудовую на руки и пенделя под зад.
Ответить | Правка | Наверх | Cообщить модератору

39. "Доступна платформа оптимизации трафика LibreQoS 1.4"  –1 +/
Сообщение от нах. (?), 01-Дек-23, 12:02 
> QoS принято настраивать везде, где есть компетентные сотрудники.

некомпетентные ты хотел сказать?

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

Если у вас есть перегрузки - расширяйте канал, это по другому не работает и бессмысленный костылепердолинг.

Ну и там вон ниже коллега пограмотнее вам расписал ЧТО на самом деле надо настраивать вместо того что вы понимаете под qos, можете оценить сколько процентов слов вы просто не понимаете, и сколько из оставшихся понятными (примерно 20?) поддерживает ваше оборудование (дайте угадаю - нисколько)

Ответить | Правка | Наверх | Cообщить модератору

41. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от Антон 19887234 (?), 01-Дек-23, 12:24 
О, администраторы офисных локалок  подтянулись со своим видением)))
Ответить | Правка | Наверх | Cообщить модератору

47. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от pofigist (?), 02-Дек-23, 20:56 
Оба два неправы
Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

6. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от Аноним (-), 30-Ноя-23, 15:22 
чесно говоря, нам для такого хватало древнего ALTQ с HFSC... Город не миллионник, но всё же.
Ответить | Правка | Наверх | Cообщить модератору

42. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от нах. (?), 01-Дек-23, 12:38 
> чесно говоря, нам для такого хватало древнего ALTQ с HFSC... Город не
> миллионник, но всё же.

в 99м году? Ну да, хватало.


Ответить | Правка | Наверх | Cообщить модератору

7. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +1 +/
Сообщение от Аноним (7), 30-Ноя-23, 15:52 
> В проведённом тесте использование LibreQoS позволило снизить задержки при приёме данных со 106 до 9 мс, а при передаче с 517 до 23 мс, ценой снижения скорости непрерывной загрузки с 74 до 25 Mbps и передачи с 29 до 8 Mbps.

Прелестно, прелестно! Платишь, как за оптику, а получаешь адсл...

Ответить | Правка | Наверх | Cообщить модератору

8. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от Аноним (5), 30-Ноя-23, 15:57 
Догадываюсь, что сейчас цена на них мало различается.
Ответить | Правка | Наверх | Cообщить модератору

28. "Доступна платформа оптимизации трафика LibreQoS 1.4"  –2 +/
Сообщение от нах. (?), 30-Ноя-23, 21:29 
Еще как различается. Сравнил считай бесплатную опту и медь закопанную в землю (ну и что что при царе горохе, и половина линий сгнила - от этого товарчик только растет в цене!)

Ответить | Правка | Наверх | Cообщить модератору

43. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от Ананий (?), 01-Дек-23, 12:47 
> и половина линий сгнила

гнило в основном в старых распред. шкафах, которые вполне себе стояли на улице со всеми вытекающими с ржавчиной и окисленными контактами.

решалось бутулкой водки для вечнопьянного монтера

Ответить | Правка | Наверх | Cообщить модератору

44. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от нах. (?), 01-Дек-23, 14:05 
ха, в шкафах, кто-то я смотрю любитель легкой жизни.

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

С другой стороны, а чего лазить-то, из ста пар еще целых шесть ничего так. И еще десяток...ну для телефонии сойдет.
Есть, есть на свете непреходящие ценности!

А на медь сдать все равно не получится - бомжи пробовали, там если изоляцию просто на костре пытаться сжечь - сгорает к чертям вместе с медью.

Ответить | Правка | Наверх | Cообщить модератору

9. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от Самый умный из вас (?), 30-Ноя-23, 16:33 
Слишком мутно написано. Скорее всего речь идёт о минимальной скорости с бурстами
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

18. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от pofigist (?), 30-Ноя-23, 19:17 
Задержки важнее потоковой скорости.
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

22. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от Аноним (16), 30-Ноя-23, 20:35 
Задержки важны постольку поскольку. Куда важднее джиттер, да и тот не всегда. Когда бэкапы льются на другую сторону планеты, мне куда важнее утилизация линка. А вот для видеосвязи, наоборот, нужен минимальный джиттер, даже если rtt высокий (а ниже не сделаешь, физика мешает).
Ответить | Правка | Наверх | Cообщить модератору

49. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от pofigist (?), 05-Дек-23, 08:32 
То что джиттер важнее задержек, не отменяет того что задержки важнее потоковой скорости.
Ибо сейчас почти все over https, то есть - tcp, а в нем задержки не позволят утилизировать канал...
Ответить | Правка | Наверх | Cообщить модератору

23. "Доступна платформа оптимизации трафика LibreQoS 1.4"  –1 +/
Сообщение от BrainFucker (ok), 30-Ноя-23, 20:38 
> повысить надёжность работы ... игр

Этим-то с какой стати? Может ещё о комфорте вейперов в общественных местах позаботиться следует? 🤦

Ответить | Правка | Наверх | Cообщить модератору

51. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от torvn77 (ok), 06-Дек-23, 18:32 
С той что если игра у абонента не пойдёт то он уйдёт к другому провайдеру, при том что монтажные работы при каждом новом подключении включая новый кабель надо выполнять заново
Ответить | Правка | Наверх | Cообщить модератору

53. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от BrainFucker (ok), 07-Дек-23, 06:08 
Провайдеров это не особо волнует, т.к. у всех +/- так же.
Ответить | Правка | Наверх | Cообщить модератору

54. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от torvn77 (ok), 07-Дек-23, 12:44 
> Провайдеров это не особо волнует, т.к. у всех +/- так же.

Но абоненты будут собираться у тех, у кого +, а не у тех, у кого минус и главное они будут давать рекомендации и звать туда своих знакомых.

И потом, подключение безплатное, то есть если абонент в поисках лучшего слишком быстро отключится то провайдер будет в убытке, так как доход от абонентской платы будет несколько месяцев только покрывать стоимость подключения.

Ответить | Правка | Наверх | Cообщить модератору

55. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от BrainFucker (ok), 07-Дек-23, 23:19 
>  провайдер будет в убытке,

Не будет, игромания это не сильно распространённо явление, тем более для большинства это тупо время убить и пофиг какой там пинг.

Ответить | Правка | Наверх | Cообщить модератору

24. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от Tron is Whistling (?), 30-Ноя-23, 20:57 
> 16-ядерным CPU Xeon Gold достаточно для обработки трафика клиентов ISP с пропускной способностью 11 gbit/s

Ну, во-первых, это очень мало.
Во-вторых не указан тип сетевых плат. Если это хотя бы BCM57416 или аналогичные - это не то, что мало, а вообще трындец.

Ответить | Правка | Наверх | Cообщить модератору

25. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +1 +/
Сообщение от Tron is Whistling (?), 30-Ноя-23, 20:58 
> снизить задержки при приёме данных со 106 до 9 мс, а при передаче с 517 до 23 мс, ценой снижения скорости непрерывной загрузки с 74 до 25 Mbps и передачи с 29 до 8 Mbps

И куда это? На ADSL?
Ну и вообще 106 и 517 - тут имхо надо что-то в другом месте лечить.

Ответить | Правка | Наверх | Cообщить модератору

26. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +8 +/
Сообщение от Аноним (26), 30-Ноя-23, 21:22 
Новость вызывает у меня бурю эмоций, и я еле-еле сдерживаюсь, чтобы не начать тролить.

Начинаем читать отсюда: https://en.wikipedia.org/wiki/TCP_offload_engine
и главное доходим до Support in Linux.

Пока другие операционные системы (Windows и FreeBSD) активно занимались разработкой собственных решений по оптимизации сетевого Linux ни черта не умел, при чем из принципа. Кстати, в конечном итоге Microsoft сдалась, закрыла свои потуги и адоптировала решения из BSD.

Затем мир перешел на оптические адаптеры по 10, 25 и выше гигабит, и оказалось, что все механизмы Offloading и QoS на самом деле очень нужны, особенно когда дело касается сетевых адаптеров с высокой пропускной способностью. Их нужно правильно готовить с Active Queue Management-ом c LRO/LSO, профилировать Interrupt Moderation, настраивать Receive Side Scaling и с учетом многпроцессорных систем и современных Scalable-процессоров (для режима Sub NUMA Clustering). Всё это существует годами, но в Linux про это мало что знают. А потом вообще пришла RDMA... но тут не в ней дело.

И вот спустя годы Linux оказался без нормального API в ядре для работы со всем этим.
Спасибо Open Fabrics (https://www.openfabrics.org/) за OFED-драйверы
Спасибо DPDK (https://www.dpdk.org/), что и в Linux есть API, но только в юзерспейсе (в этом смысл DPDK)

Результат который мы наблюдаем сейчас:
1. Драйвер Bonding в ядре - это страшный мусор, который нужно удалить. Он не поддерживает вообще ничего
2. LRO, LSO, RSS и Interrupt Moderation есть, но по большей части всё это находится в драйверах
3. Автоматических настроек, профилирования нет. Народ даже ethtool до конца не понимает
4. QoS и AQM на принимающей стороне сетевого стека отсутствует, вместо него есть возможность что-то наваять на **tables.
5. Linux Virtual Switch - мусор из 90-х, который не отвечает современным потребностям
А потом спрашивается, а чего это все коммутаторы проприетарные, даже те, в которых Linux используется... Ну ок, есть Cumulus Linux (желаю удачи его скачать), но он живой пример, как можно сделать проприетарь на базе GPL.

Стыд в том, что настольная версия Windows всё это поддерживает правильно и позволяет себя перенастроить... Шел 2023-й год и в Linux задумались, что у них в сетевом стеке что-то не так. Вся эта беспробудная тупость усугубляется тем, что слишком много людей в Linux верующие фанатики. На этот раз они верят в то, что сетевки Intel - нормальные. Нет! Это адаптеры, в которых сломаны все эти механизмы и в которых каждый год выходит обновление драйвера, выпиливающее что-нибудь, потому что нашли баги. В общем в 2023-ем году вне Mellanox и Chelsio жизни нет. И если в том же Linux максимально пользоваться из драйверами и минимально всем что есть в системе, то оно будет работать.

Дальше эти фантазии про QoS. Я ведь зашел на унылый лендинг LibreQoS (ускорятеля видеоигр через QoS). Я даже видео посмотрел. Было сложно, было стыдно, но я посмотрел! Причем они рассказывают про игры, будто это домашнее решение.

Давайте на минуточку забудем про LibreQoS и ISP-задачи и поговорим, как должен выглядеть современный QoS...
(тем кто в таке гуглите слова сами)
Вот вы включили AQM на стороне сетевого адаптера и роутера. Вы настроили Weghted Random Early Detection (WRED) и Explicit Congestion Notification, который радостно прописался в ваши заголовки IP. Допустим вы настроили DCTCP (Datacenter TCP) как Congestion Control вместо CUBIC и начали уважать ECN для задач управления потоком TCP. Но этого мало, вы должны использовать иерархический QoS для реального разграничения трафика, то есть ваш коммутатор поддерживает Enhanced Transmission Selection (ETS).

У вас нормальный такой коммутатор/роутер, но сетевой адаптер тоже должен всё это уметь (Intel свой забудьте). Например, вы купили NVIDIA/Mellanox и радостно настроили OFED, очереди и QoS, благо для Linux это можно сделать средствами прошивки и драйвера.

И вот он наконец-то у вас появился ваш QoS. Красивый иерархический с дележками на типы трафика и резервацией буфера, с поддержкой Assured Forwwarding (предоставления гарантированной пропускной способности канала). Дальше что?!

DSCP вам удалят при попадании пакетов из вашей сети в сеть провайдера, если только вы не купили L1 через DWDM или L2VPN. А что пройзойдет с QoS, когда провайдер перемаркирует DSCP? Правильно ваш QoS и ваш Congestion Control разуплотняется на субатомные частицы.

А если у вас Datacenter и Storage-сети поверх Ethernet, ваш QoS обязан держать Flow Control на приоритетах 802.1p с использованием Priority Based Flow-controil (PFC) и затем трансформировать их в DSCP в направлении вашей L3-фабрики. Сочетание AQM(WRED)+ETS+ECN+PFC=DCQCN Datacenter Quantized Congestion Notification.

Применение DCQCN позволяет:
- полностью убрать slowstart-образные механизмы и полагаться на PFC, устанавливая соединения со скоростью линка
- не терять пакеты вообще (нет ретрансмитов), потому что у вас ECN сообщает заранее о грядущей перегрузке
- а если источник потока не снизил скорость (Transmission Rate), то за дело возьмётся PFC
Естественно и ваши коммутаторы и ваши сетевые адаптеры поддерживают решения типа PFC Watchdog средствами прошивки, потому что PFC-это peer-to-peer QoS и он может штормить при неверной настройке.

И вот они ваши сетевки наконец-то получили пакеты в буферы. Ура!

Что там за проблема у вас? Снижение задержек на TCP? Обычно люди для таких вещей UDP используют (те же P2P-сети обозначенных в видосе видеоигр), а большинство оффлоадингов типа Large Recieve Offload, он же Receive Segment Coalescing, он же Generic Receive Offload не затрагивает протокол UDP по вполне очевидной причине. В UDP в общем случае нет понятия сессий, и сетевой адаптер не поймет как склеивать UDP пакеты перед отправкой в CPU.

Так что же тогда делает LibreQoS?! И почему пишет про чятики и видеоигры?
То есть какую задачу он решает? Что такое случилось? Предлагает собственную реализацию поллинг из буфера NIC? Собсвенную реализацию RSS? И с каких пор шейпинг помагает задержкам?! Шейпинг их создаёт!!! В этом его суть, он уберает Packet Burst внутрь буфера вместо того чтобы дропнуть или ставить на паузу (PFC) или уведомлять заранее (WRED) огрядущей перегрузке очередей, средствами ECN? Чем они вообще там занимаются?

А давайте посмотрим сюда:
https://libreqos.readthedocs.io/en/latest/docs/Quickstart/ne...
Ох ёж твою медь! Это решение для мамкиного ISP!

Оно не поддерживает MPLS (я не удивлён) и скорее всего VXLAN тоже, причем эти странные личности пишут про OSPF... то есть не eBGP+ECMP, а вот именно OSPF, ну да ладно, это мелочи. Главное что оно сервис в смысле Service Chaining включения, как граничный файрвол, DPI и прочий NAT-перенат. Оно заворачивает на себя декапсулированный трафик. А может задержки снизятся если этой штуки вообще там нет, а вместо этого у вас просто есть QoS на сетевом оборудовании?

Лучше сделать не как бомжи, а распространить Diffserv-домен на всю свою L3-фабрику и сделать правильный мапинг к PCP-приоритетам на L2-границе. Зачем этот костыль, который под капотом решает только одну единственную проблему, проблему убогости ядра Linux и его сетевого стека. И вот после героического решения проблем убогости они на Linux (создание логики очередей поверз eBPF) они создают волшебный QoS, который средствами шейпинга (sic!) снижает задержки. А про уменьшение буферизации за счет установки дополнительного сервера в цепочку на выходе трафика - это прямо анекдот. Ох, что люди только не придумают лишь бы Diffserv не настраивать.

Я к тому что такие решения существуют но они не бесплатные. Тот же SQN QoS, когда теннанты инкапсулируются в VXLAN. Они есть даже как продукты, которые ставятся на Linux, главное только настоящий трафик туда не заворачивать. Оркестрировать и мониторить можно, только не заворачивать трафик, потому что Linux и QoS... ой всё.
Может проще Juniper купить? Или что вам там больше нравится, только нормальное?

P.S. Я такой едкий сегодня, потому что это псевдопродукт, с красивым лендингом, весь такой ускоряющий видеоигры и зумы. А на самом деле - это сервисчейн, который ставит мультифилд-классификаторы и шейпит один трафик в угоду другому, причем так, что создаёт бутылочное горлышко. Я бы понял, если бы это преподносилось как очередной раковый шейпер, который VK сделает быстрее, а Youtube медленнее и привяжет это к тарифной сетке:
https://libreqos.readthedocs.io/en/latest/docs/TechnicalDocs...
Ой, так это же оно и есть!

Ответить | Правка | Наверх | Cообщить модератору

48. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от PnD (??), 04-Дек-23, 12:25 
Ну, в общем Вы пожалуй правы.
Но в частности кое-что можно и с linux. Если ограничить хотелки до l2, приоритеты вполне себе разводятся через htb, с очередями pfifo_fast и fq_codel (наследник multiq) по смыслу.
Бондинг как таковой (что LACP что A/S) при такой схемотехнике особых проблем не доставляет.
А вот растегирование vlan в linux, НЯЗ, до сих пор упирается в 1 поток.

В общем, заставить гипервизор пулять полтос (25+25) до ближайшего свитча — вполне реально штатными средствами. Хотя и не бесплатно (особенно в паре с qemu).
Дальше — да, linux — максимум на правах управлялки ASIC'ами в whitebox'е.

Ответить | Правка | Наверх | Cообщить модератору

52. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от torvn77 (ok), 06-Дек-23, 19:13 
>Linux ни черта не умел, при чем из принципа.  

Было вполне оправданное и актуальное сейчас опасение что любое нарушение нейтралитета сети может создать неконкурентные преимущества тем или иным компаниям и дискриминацию остальных компаний не имеющих прямого доступа к телу бмзнесменеджеров провайдера.  

>будто это домашнее решение.  

Если учесть то, что бутылочное горлышко современных конечных сетей это WiFi то может так оно и есть?  
Затормозила вайфайная сетка у гиков вот они и зашевелились.

>Ой, так это же оно и есть!  

Значит ещё одна заинтересованная сторона, причём довольно платёжеспособная, хотя для рунета софтварная манипуляция пакетами это плохая новость.

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

31. "Доступна платформа оптимизации трафика LibreQoS 1.4"  –1 +/
Сообщение от Аноним (31), 01-Дек-23, 04:05 
NetLimiter еще есть. А вообще это не серьезно, эту работу должно выполнять железо.
Ответить | Правка | Наверх | Cообщить модератору

40. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от нах. (?), 01-Дек-23, 12:04 
> NetLimiter еще есть. А вообще это не серьезно, эту работу должно выполнять
> железо.

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

Ответить | Правка | Наверх | Cообщить модератору

37. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от VNV (?), 01-Дек-23, 09:37 
Как интересно это будет работать в случае нескольких аплинков и ассиметричного трафика?
Ответить | Правка | Наверх | Cообщить модератору

45. "Доступна платформа оптимизации трафика LibreQoS 1.4"  +/
Сообщение от нах. (?), 01-Дек-23, 14:07 
> Как интересно это будет работать в случае нескольких аплинков и ассиметричного трафика?

так же точно как и в случае одного и симметричного.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру