Результат сравнения различных шейперов
-
Задача была следующая:
1. Не загонять торренты в узкую полосу. Если канал свободен - пусть качают на 100% канала.
2. Обеспечить нормальную работу Skype, который в силу своей хитрозадости использует случайные порты и в итоге попадает в одну очередь с торрентами.
3. Обеспечить независимость пинга в онлайн играх от торрентов. Проверялось на world of warcraft.
4. Обеспечить нормальную отзывчивость вебсайтов, ютуба и т.п. http трафика.В конце я напишу настройки для оптимального (на мой взгляд) варианта.
Что было испробовано (Scheduler Type)
1. PRIQ
2. HFSC
3. FAIRQВо всех случаях скорость интерфейса ставилась в 95% он реальной.
Важное замечание: pfsense глючит когда в очередях использованы проценты, а потом надо изменить скорость интерфейса, поэтому лучше использовать абсолютные значения. Я буду все писать в процентах чтобы не завязываться на конкретные цифры.Структура очередей
Во всех случаях структура очередей нижнего уровня была одинаковая (от верхнего приоритета к нижнему):
qAckGames (ACK для игрового траффика)
qGames (игровой траффик)
qAck (ACK для всего, кроме торрентов)
qHigh (DNS запросы и т.п.)
qInternet (порты ниже 1024 и 8080)
qPTP (все остальное - Default Queue)PRIQ
Не смотря на расстановку приоритетов торренты увеличивают игровой пинг с 50 до 200 и выше. Сайты открываются с задержкой, ютуб тупит.
Вердикт: В мусорную корзинуHFSC
Тут все сложнее в силу массы вариантов конфигурации HFSC. Кроме того HFSC не поддерживает приоритеты (по крайней мере в этом уверен автор pfsense, т.к. значение приоритета просто игнорируется что видно по команде "pfctl -sq" в Diagnostics->Command Prompt).
Т.к. стояла задача не резать скорость, был использован подход описанный здесь http://hackedfiles.blogspot.ru/2014/08/pfsense-hfsc-deep-understanding.html. Во всех очередях используется исключительно параметр Link Share, игнорируя Bandwidth и прочее. Это позволяет шейперу гибко распределять полосу, отдавая ее полностью торрентам, если нет активности в других очередях. Для всех очередей активирован алгоритм Codel Active Queue, который отбрасывает пакеты до того как они забъют собой канал, а не по факту его забития.Результат позитивный. Торренты качают на полную, но уступают полосу http и игровому трафику при его появлении.
Skype работает нормально при условии активации Codel Active Queue для qPTPСтруктура очередей:
WAN (Scheduler Type: HFSC, Bandwidth: 95% от скорости upload интернет канала)- qUpload (linkshare m2: 100%) - очередь верхнего уровня
– qAckGames (Codel Active Queue, linkshare m2: 5%)
-- qGames (Codel Active Queue, linkshare m2: 10%)
-- qAck (Codel Active Queue, linkshare m2: 20%)
-- qHigh (Codel Active Queue, linkshare m2: 10%)
-- qInternet (Codel Active Queue, linkshare m2: 48%)
-- qPTP (Queue Limit: 500, Codel Active Queue, linkshare m2: 1%)
LAN (Scheduler Type: HFSC, Bandwidth: 95% от скорости download интернет канала) - qDownload (linkshare m2: 100%) - очередь верхнего уровня
-- qAckGames (Codel Active Queue, linkshare m2: 5%)
-- qGames (Codel Active Queue, linkshare m2: 10%)
-- qAck (Codel Active Queue, linkshare m2: 20%)
-- qHigh (Codel Active Queue, linkshare m2: 10%)
-- qInternet (Codel Active Queue, linkshare m2: 48%)
-- qPTP (Queue Limit: 500, Codel Active Queue, linkshare m2: 1%)
Под них настроенты Firewall->Rules->Floating (пример для очереди qInternet):
Action: Match
Interface: WAN
Direction: any
Protocol: tcp/udp
Destination port range: 1 - 1024
Ackqueue / Queue: qAck, qInternetFAIRQ
Алгоритм покрыт завесой тайны и не документирован. Например чтобы понять диапазон приоритетов (0-7) пришлось залезть в исходные коды freebsd (altq_fairq.c).
Порядок его работы упрощенно следующий:
1. Берется очередь с наивысшим приоритетом. Если она не переполнена, то обрабатывается ее пакет по FIFO
2. Если очередь с наивысшим приоритетом переполнена, то анализируется следующая по приоритету. Если она не переполнена, то обрабатывается.
3. Если все очереди переполнены, то обрабатывается очередь с наивысшим приоритетом.Для всех очередей активируется Codel Active Queue, чтобы отсекать лишний трафик до того как он попадет на обработку планировщику FAIRQ.
Результат: великолепный. Торренты качают на полную, но сразу уступают трафику с высшим приоритетом. Пинг стоит в играх на месте при любых попытках захламить канал. Причем исходя из алгоритма, это должно быть эффективнее чем предыдущий вариант, т.к. тут работают приоритеты.
Skype работает нормально при условии активации Codel Active Queue для очереди qPTPСтруктура очередей:
WAN (Scheduler Type: FAIRQ, Bandwidth: 95% от скорости upload интернет канала)- qAckGames (Priority: 7, Codel Active Queue, Bandwidth: 5%)
- qGames (Priority: 6, Codel Active Queue, Bandwidth: 10%)
- qAck (Priority: 5, Codel Active Queue, Bandwidth: 20%)
- qHigh (Priority: 4, Codel Active Queue, Bandwidth: 10%)
- qInternet (Priority: 3, Codel Active Queue, Bandwidth: 48%)
- qPTP (Priority: 2, Queue Limit: 500, Codel Active Queue, Bandwidth: 1%)
LAN (Scheduler Type: FAIRQ, Bandwidth: 95% от скорости download интернет канала) - qAckGames (Priority: 7, Codel Active Queue, Bandwidth: 5%)
- qGames (Priority: 6, Codel Active Queue, Bandwidth: 10%)
- qAck (Priority: 5, Codel Active Queue, Bandwidth: 20%)
- qHigh (Priority: 4, Codel Active Queue, Bandwidth: 10%)
- qInternet (Priority: 3, Codel Active Queue, Bandwidth: 48%)
- qPTP (Priority: 2, Queue Limit: 500, Codel Active Queue, Bandwidth: 1%)
Firewall->Rules->Floating аналогичны настройкам для HFSC.
P.S. Оговорюсь сразу, что я не сисадмин и это результаты натурных экспериментов, а не глубоких знаний работы шейпера freebsd.
- qUpload (linkshare m2: 100%) - очередь верхнего уровня
-
Firewall->Rules->Floating аналогичны настройкам для HFSC.
Картинки, картинки!
Спасибо.
-
Картинки, картинки!
И до полноценного мануала останется 1 шаг!
-
А что за FAIRQ? У меня последняя ночнушка 2.3.1 в ней только: CBQ, PRIQ, HFSC.
-
Firewall->Rules->Floating аналогичны настройкам для HFSC.
Картинки, картинки!
Спасибо.
Чтобы делать картинки, мне надо поломать текущую конфигурацию, которая отличается от рассмотренной наличием 2х wan. Все нужные настройки расписаны в текстовом виде.
Текущая конфигурация (Diagnostics->Command Prompt-> pfctl -sq):
queue qPTP on ale0 bandwidth 1Mb priority 2 qlimit 500 fairq( codel default linkshare 95Mb )
queue qAckGames on ale0 bandwidth 5Mb priority 7 fairq( codel linkshare 95Mb )
queue qGames on ale0 bandwidth 10Mb priority 6 fairq( codel linkshare 95Mb )
queue qHigh on ale0 bandwidth 10Mb priority 4 fairq( codel linkshare 95Mb )
queue qInternet on ale0 bandwidth 49Mb priority 3 fairq( codel linkshare 95Mb )
queue qACK on ale0 bandwidth 20Mb priority 5 fairq( codel linkshare 95Mb )
queue qPTP on re1 bandwidth 1Mb priority 2 qlimit 500 fairq( codel default linkshare 45Mb )
queue qAckGames on re1 bandwidth 5Mb priority 7 fairq( codel linkshare 45Mb )
queue qGames on re1 bandwidth 5Mb priority 6 fairq( codel linkshare 45Mb )
queue qHigh on re1 bandwidth 4Mb priority 4 fairq( codel linkshare 45Mb )
queue qInternet on re1 bandwidth 20Mb priority 3 fairq( codel linkshare 45Mb )
queue qACK on re1 bandwidth 10Mb priority 5 fairq( codel linkshare 45Mb )
queue qPTP on pppoe0 bandwidth 1Mb priority 2 qlimit 500 fairq( codel default linkshare 45Mb )
queue qAckGames on pppoe0 bandwidth 5Mb priority 7 fairq( codel linkshare 45Mb )
queue qGames on pppoe0 bandwidth 5Mb priority 6 fairq( codel linkshare 45Mb )
queue qHigh on pppoe0 bandwidth 4Mb priority 4 fairq( codel linkshare 45Mb )
queue qInternet on pppoe0 bandwidth 20Mb priority 3 fairq( codel linkshare 45Mb )
queue qACK on pppoe0 bandwidth 10Mb priority 5 fairq( codel linkshare 45Mb ) -
А что за FAIRQ? У меня последняя ночнушка 2.3.1 в ней только: CBQ, PRIQ, HFSC.
У меня доступны еще CODELQ и FAIRQ. Версия:
2.3-RELEASE (amd64)
built on Mon Apr 11 18:10:34 CDT 2016
FreeBSD 10.3-RELEASE -
В версии 2.3_1 их целых пять:
HFSC, CBQ, FAIRQ, CODELQ, PRIQ.
Остались не протестированы CBQ и CODELQ.
Будете их тестировать?Ещё вопрос по динамическому шейпингу по количеству пользователей, реализовано ли это?
Т.е. один пользователь - ему весь канал, два - пополам каждому, десять - десятая часть каждому,
и у каждого приоритеты по трафику. -
@3vs:
Ещё вопрос по динамическому шейпингу по количеству пользователей, реализовано ли это?
Т.е. один пользователь - ему весь канал, два - пополам каждому, десять - десятая часть каждому,
и у каждого приоритеты по трафику.Это limiter. И это другое совсем.
-
@3vs:
В версии 2.3_1 их целых пять:
HFSC, CBQ, FAIRQ, CODELQ, PRIQ.
Остались не протестированы CBQ и CODELQ.
Будете их тестировать?Смысл тестировать CBQ, если HFSC это его продвинутый потомок? А CODELQ вообще не имеет дочерних очередей, поэтому для описанной задачи не подходит.
-
Вопрос- есть шейпер с портами как в топике 1-1024, 8080 і 3124. Но трафик страничек не попадает в правило Internet, а попадает в правило p2p которое есть "Default Queue". Стоит Squid в Transparent mode.
-
Вопрос- есть шейпер с портами как в топике 1-1024, 8080 і 3124. Но трафик страничек не попадает в правило Internet, а попадает в правило p2p которое есть "Default Queue". Стоит Squid в Transparent mode.
Потому как Squid работает на 3128 порту. Добавьте дополнительное правило для локальной сети в сторону 127.0.0.1:3128.
Хотя transparent squid и Limiter обычно плохо отрабатывает. На шейпере не пробовал. -
Спасибо, тут не правильно написал 3124, хотя в настройках 3128. Попробую справилом на lan интерфейсе.