[more]
Constantin_ Цитата: если с Max Limit все ясно, то Limit At - это параметр который выходит из расчета текущей загруженности канала и кол-ва работающих юзеров
конечно если ваш внешний канал покрывает все потребности работающих клиентов то эти параметры не нужны, но у кого это так????
и вот если реализовать в билинге просчет этого параметра Limit At (а это было бы супер) то нагрузка будет неплохая для компа на котором этот билинг крутиться
Тут я не всё у вас понял. Параметр LImit AT не "выходит из расчёта". Если поток в очереди имеет этот параметр, то при перегрузке очереди, приоритет имеют именно пакеты из этого потока и именно не менее этой скорости. Это основы QoS. Использовать LimitAT нужно лишь если вы выделяете какой то конкрентый вид трафика из всего потока.
И всё-таки настоятельно рекомендую те доки к прочтению. То, о чём вы говорите реализовано на алгоритме PCQ.
Если внешний канал не покрывает общий запрос, то, при отсутствии всех прочих параметров, всем пользователям обрезается скорость симметрично. Если же вы не укажите в PCQ сколько нужно резать одному пользователю (на один пир, не обязательно пользователь, это может быть целая подсеть), то весь канал будет разделён поровну между всеми пользователями или подсетями, причём одним единственным правилом..
Например, у меня на Ямале есть сеть, где на всех раздаётся всего 1,5 мб/с. Конечно, изначально должна быть известна общая физическая пропускная способность канала, иначе, как же её узнать? Это значение является корневым на всю очередь. Конечно, глупо делить на всех пользователей примерно по 5-10 кб/с, поэтому там нет ограничений на пользователя. Если реально работает один, то у него будет 1,5 мб/с, у двух уже по 750 кб/с и т.д.
Кстати,
вы интересовались, зачем маркировать соединения, а уже в них пакеты. Всё просто, в очередь должны попасть и те пакеты, у которых src.address не совпадает с внутренним IP абонента, ведь возвращающийся пакет уже идёт с другим src.sddr. Если этого не сделать, то придётся отдельно маркировать ещё и входящие пакеты, причём, они не факт, что будут принадлежать к тому же соединению. И, конечно, шейпиться скорость будет неправильно.
А вот промаркировав соединение, вы гарантируете, что в Очередь попадёт и то, что придёт из Интернета на конкретный исходящий запрос, а если этого не сделать, то в очередь попадёт только то, что от абонента улетит в Интернет и PCQ не сможет разделить этот траффик между абонентами, получиться как раз неправильное шейпирование. А вот применять очередь к соединениям нельзя, только к пакетам, поэтому чисто формально после маркировки конкретного соединения определённой группы (например, принадлежащей к одному тарифу) мы должны отмаркировать там пакеты. Получается, всего по паре правил на один тариф (сразу на вход и исход), а не по правилу на каждого абонента.
Для примера на тему, попробуйте решить такую задачку. У Вас есть Два провайдера (Основной и Бэкап всё за NAT). Роутинг по умолчанию на одного основного провайдера. Бэкап-провайдер с отдельным неосновным маршрутом (в отдельной таблице маршрутизации). Нужно сделать средствами Мангл так, что бы прилетающий запрос от не основного провайдера улетал туда, откуда пришёл, например, если это обращение по 25 порту, то Почтовый сервер работать просто через DST-NAT не будет, поскольку ожидает ответ на запрос именно с того же адреса, на который запрос отправил.
Честно признаться, очень интересно, как же Вы без этого настроили Шейпинг на базе Деревьев. Если не сложно, выложите экспорт, пожалуйста, ваших Мангл правил и Деревьев очередей. Возможно, вы как то иначе реализовали эту функцию? [/more]
В ТИ с этим было лучше. Все балансы правились в соответствии с временем работы клиентов, начиная с даты начала их работы и до даты системных часов. А тут балансы движуться только вперед.