Затем что я админ и не знаю php. Совсем не знаю. Правда.
Поэтому я его слепил из того, что было и send_from_pbx.php закрыл nginx-ом для всех, кроме IP астериска.
у меня ammyy куплен, но регулярно приходится использовать TV, т.к. если ammyy запущен из под пользователя (или даже с админскими правами, но не как сервис), он:
а) рвёт соединение при любом запросе UAC (это понятно и терпимо)
б) сходит с ума, если у пользователя два монитора, а тем более, если у них разное разрешение
Тем не менее, тех небольших денег, которые уплачены за ammyy не жалко, в своих рамках это отличное решение (которое работает из под wine без проблем. Иногда это важно).
Мне как-то в наследство проект достался, где сессии хранились в БД и хранились они по году (или по два, не помню уже). В общем таблица распухла до каких-то феерических значений и было принято решение очистить её, оставив данные за последний месяц.
Тогда-то я радостно по граблям в первый раз и проскакал.
А значения из статьи честно утянуты из этой заметки в ru_root. Она мне живо напомнила мой печальный опыт.
Ну да, поэтому у меня и маркируются только пакеты, а не соединения (а жаль, я бы ещё короткие http-соединения от длинных отделил).
pfifo тупо потому что оно по умолчанию. Я честно прочёл документацию, но не очень понял как виды очередей повлияют на приоретизацию. С делением канала понятно, а вот в моём случае — не очень.
Честно говоря, в основном, чтобы разобраться, как работает приоритезация трафика в микротике.
Потому что по мере чтения документации и примеров из вики возникло недопонимание.
Хороший вопрос. Для 5060 и 5061 скорее всего нет, но там просто SIP, он просто управляет сессией.
Мне кажется, что малые задержки критичнее для RTP-трафика, а вот с ним сложнее.
С одной стороны, должно быть достаточно выставлять TOS на сервере и определять трафик по нему (через поле DSCP/TOS), с другой — я решил перестраховаться и определять его по протоколу и диапазону портов.
Короче, в примере я перестраховался на всякий случай.
На всякий случай сверился с документацией. В вики сказано следующее:
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. Спасибо за вопрос, благодаря нему ещё раз проверил скрипты и нашёл в них ошибку, из-за которой трафик не распределялся по очередям (неверно указал цепочки. Сейчас исправлю)
Да, всё верно. Но есть небольшой нюанс — я не пытаюсь шейпить трафик, я пытаюсь его эквалайзить.
Т.е. провайдер может урезать всё как он считает нужным, но под нож пойдут пакеты из prio_5, а их не жалко.
Но всё равно — отличные комментарии, спасибо ещё раз.
Поэтому я его слепил из того, что было и send_from_pbx.php закрыл nginx-ом для всех, кроме IP астериска.
а) рвёт соединение при любом запросе UAC (это понятно и терпимо)
б) сходит с ума, если у пользователя два монитора, а тем более, если у них разное разрешение
Тем не менее, тех небольших денег, которые уплачены за ammyy не жалко, в своих рамках это отличное решение (которое работает из под wine без проблем. Иногда это важно).
скорость как у VNC в худших его проявлениях, а удобство ммм… не очень.
В общем, мне не понравилось.
Тогда-то я радостно по граблям в первый раз и проскакал.
А значения из статьи честно утянуты из этой заметки в ru_root. Она мне живо напомнила мой печальный опыт.
Но я правильно понимаю, что в таком случае нужно делать две очереди, для входящего и исходящего трафика?
Хотя сейчас я.маркет говорит, что уже за 6.5 есть, но то в Москве.
pfifo тупо потому что оно по умолчанию. Я честно прочёл документацию, но не очень понял как виды очередей повлияют на приоретизацию. С делением канала понятно, а вот в моём случае — не очень.
Потому что по мере чтения документации и примеров из вики возникло недопонимание.
Нагрузка на процессор 67% максимум.
Мне кажется, что малые задержки критичнее для RTP-трафика, а вот с ним сложнее.
С одной стороны, должно быть достаточно выставлять TOS на сервере и определять трафик по нему (через поле DSCP/TOS), с другой — я решил перестраховаться и определять его по протоколу и диапазону портов.
Короче, в примере я перестраховался на всякий случай.
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. Спасибо за вопрос, благодаря нему ещё раз проверил скрипты и нашёл в них ошибку, из-за которой трафик не распределялся по очередям (неверно указал цепочки. Сейчас исправлю)
Т.е. провайдер может урезать всё как он считает нужным, но под нож пойдут пакеты из prio_5, а их не жалко.
Хотя могу ошибаться, разумеется.