Comments 27
Очень содержательная статья на тему: https://habrahabr.ru/post/307214/
родительскую очередь (у Вас QoS_global) нужно брать чуть уже, чем скорость от провайдера
max-limit=30M — в условии задачи указано что канал у нас выдает 32 метра, но прописывать нужно чуть меньше доступной скорости. В противном случае вы упретесь в шейпер своего провайдера, ваш же просто не будет работать.
родительскую очередь (у Вас QoS_global) нужно брать чуть уже, чем скорость от провайдера
Да, всё верно. Но есть небольшой нюанс — я не пытаюсь шейпить трафик, я пытаюсь его эквалайзить.
Т.е. провайдер может урезать всё как он считает нужным, но под нож пойдут пакеты из prio_5, а их не жалко.
Хотя могу ошибаться, разумеется.
Т.е. провайдер может урезать всё как он считает нужным, но под нож пойдут пакеты из prio_5, а их не жалко.
Хотя могу ошибаться, разумеется.
Насколько я понял из указанной статьи — дочерние очереди («prio_». "$indexA") не будут отбрасывать / задерживать пакеты, пока у родителя (QoS_global) не сработает отсечка (max-limit, limit-at и т.д.)
На всякий случай сверился с документацией. В вики сказано следующее:
1. https://wiki.mikrotik.com/wiki/Руководства: Очередь_(Queue)
В дереве очередей отсутствует строгая последовательность обработки трафика как в простых очередях – весь трафик попадает в необходимые очереди сразу, одновременно.
2. https://wiki.mikrotik.com/wiki/Руководства:HTB
Каждая очередь в HTB обладает двумя ограничениями на скорость передачи данных: CIR (гарантированная скорость) и MIR (максимальная скорость). Сначала будет удовлетворено значение limit-at (CIR) всех очередей, и только затем дочерние очереди будут пытаться «одолжить» необходимую им скорость передачи данных у своих родительских очередей для того, чтобы достичь своих значений max-limit (MIR).
т.е., похоже что нет, отсечки ждать не обязательно.
P.S. Спасибо за вопрос, благодаря нему ещё раз проверил скрипты и нашёл в них ошибку, из-за которой трафик не распределялся по очередям (неверно указал цепочки. Сейчас исправлю)
1. https://wiki.mikrotik.com/wiki/Руководства: Очередь_(Queue)
В дереве очередей отсутствует строгая последовательность обработки трафика как в простых очередях – весь трафик попадает в необходимые очереди сразу, одновременно.
2. https://wiki.mikrotik.com/wiki/Руководства:HTB
Каждая очередь в HTB обладает двумя ограничениями на скорость передачи данных: CIR (гарантированная скорость) и MIR (максимальная скорость). Сначала будет удовлетворено значение limit-at (CIR) всех очередей, и только затем дочерние очереди будут пытаться «одолжить» необходимую им скорость передачи данных у своих родительских очередей для того, чтобы достичь своих значений max-limit (MIR).
т.е., похоже что нет, отсечки ждать не обязательно.
P.S. Спасибо за вопрос, благодаря нему ещё раз проверил скрипты и нашёл в них ошибку, из-за которой трафик не распределялся по очередям (неверно указал цепочки. Сейчас исправлю)
У вас жестко указаны IP адреса для SIP трафика, нужно ли это?
Хороший вопрос. Для 5060 и 5061 скорее всего нет, но там просто SIP, он просто управляет сессией.
Мне кажется, что малые задержки критичнее для RTP-трафика, а вот с ним сложнее.
С одной стороны, должно быть достаточно выставлять TOS на сервере и определять трафик по нему (через поле DSCP/TOS), с другой — я решил перестраховаться и определять его по протоколу и диапазону портов.
Короче, в примере я перестраховался на всякий случай.
Мне кажется, что малые задержки критичнее для RTP-трафика, а вот с ним сложнее.
С одной стороны, должно быть достаточно выставлять TOS на сервере и определять трафик по нему (через поле DSCP/TOS), с другой — я решил перестраховаться и определять его по протоколу и диапазону портов.
Короче, в примере я перестраховался на всякий случай.
В домашних условиях QoS вообще лишний — у домашних микротов на него мощностей толком не хватит — модели с вайфаем прокачают мегабит 60-70 торрентами и захлебнутся.
Одно время ограничивал количество соединений на адрес, но потом и на это забил.
Одно время ограничивал количество соединений на адрес, но потом и на это забил.
А сколько по вашему нужно на QoS? Я думал для домашнего использования 720МГц MIPS'а вполне хватает, а некоторые могут себе и что-то из CloudCore серии поставить, если частный дом и видеонаблюдение, а там уже 9x1ГГц и выше.
Ну, я на двух 100М линках дома выжимал на торрентах 150 мегабит в пике, а в среднем было 110-130.
Нагрузка на процессор 67% максимум.
Нагрузка на процессор 67% максимум.
кстати, было ощущение, что скорость закачки тупо в производительность винта упёрлась.
Странный у вас хард.
По теме — два линка 80 и 100 на балансировке выжимали из торрента примерно 150-160, что сходится с теоритическим средним в удвоенную минимальную пропускную способность двух интерфейсов. Качал на SSD (чтоб точно не учитывать ограничение HDD, а так конечно насилие над твердотельником). Нагрузка до 30% на Hap AC. Это учитывая неидеальность настройки и отключеный fastpath. Без QoS, конечно.
По теме — два линка 80 и 100 на балансировке выжимали из торрента примерно 150-160, что сходится с теоритическим средним в удвоенную минимальную пропускную способность двух интерфейсов. Качал на SSD (чтоб точно не учитывать ограничение HDD, а так конечно насилие над твердотельником). Нагрузка до 30% на Hap AC. Это учитывая неидеальность настройки и отключеный fastpath. Без QoS, конечно.
Если с фаст-треком (читай без коса ибо фасттрек не закосишь) то вообще не вопрос, а вот с простой приоритезацией, через которую идёт весь трафик, мой 951G на 650МГц захлёбывался на уровне 55-65мбит.
3011RM запросто торренты на 300-350 мегабит качает. Проверено лично.
QoS в микротике боль и страдания, когда у тебя несколько провайдеров, несколько тунелей…
Кстати, почему pfifo, а не pcq?
Кстати, почему pfifo, а не pcq?
Ну да, поэтому у меня и маркируются только пакеты, а не соединения (а жаль, я бы ещё короткие http-соединения от длинных отделил).
pfifo тупо потому что оно по умолчанию. Я честно прочёл документацию, но не очень понял как виды очередей повлияют на приоретизацию. С делением канала понятно, а вот в моём случае — не очень.
pfifo тупо потому что оно по умолчанию. Я честно прочёл документацию, но не очень понял как виды очередей повлияют на приоретизацию. С делением канала понятно, а вот в моём случае — не очень.
Если у вас в домашней сети только один компьютер, то pfifo достаточно, только буфер дефолтный можно увеличить. Если же несколько устройств, то необходима очень pcq, это позволит в рамках одного класса трафика поделить полосу пропускания и нивелировать загрузку канала одним из устройств ( буферы тоже можно подкрутить, ну и бёрст по желанию).
Это круто. Но зачем?
Даунстрим трафик все равно контролирует провайдер. Приоритезация его имеет смысл только если у вас локальная сетка дома имеет меньшую полосу, чем куплен канал.
А апстрим в 99% случаев у вас будет свободен. А в остальном 1% случаев проще зарезать полосу в торрент-клиенте.
Даунстрим трафик все равно контролирует провайдер. Приоритезация его имеет смысл только если у вас локальная сетка дома имеет меньшую полосу, чем куплен канал.
А апстрим в 99% случаев у вас будет свободен. А в остальном 1% случаев проще зарезать полосу в торрент-клиенте.
Честно говоря, в основном, чтобы разобраться, как работает приоритезация трафика в микротике.
Потому что по мере чтения документации и примеров из вики возникло недопонимание.
Потому что по мере чтения документации и примеров из вики возникло недопонимание.
Так вижу: если дома торрентокачалка решила покачать на полную, а мне приспичило по зуму поговорить — то надо чтобы торренты сами притормозили :)
UFO just landed and posted this here
Sign up to leave a comment.
Mikrotik. QoS для дома