abramoff Опубликовано 17 мая, 2013 · Жалоба Добрый день, Хочется реализовать такой алгоритм управления трафиком: есть два класса - скажем c1 и c2. Есть некий хост IP (вообще их много, нужно подумать о хешировании), который занимает (потребляет) некоторую полосу R (байт/сек). Пока R<L (L - некий заданный лимит полосы), трафик для IP классифицируется в c1. При превышении (когда R>L) - весь трафик для IP (а не только "перелив") переклассифицируется в с2. При уменьшении занимаемой полосы R ниже лимита L трафик для IP возвращается обратно в c1. В итоге, идея простая: "начал качать, превысил некий лимит байт/сек - пожалуй в другой класс". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bomberman Опубликовано 17 мая, 2013 · Жалоба Почему нельзя сразу дать качать на максимальной скорости, которой можно? Или я не верно понял задачу? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
abramoff Опубликовано 17 мая, 2013 · Жалоба Почему нельзя сразу дать качать на максимальной скорости, которой можно? Или я не верно понял задачу? Можно качать сразу на макс. скорости. Надо, чтобы весь трафик (а не только overlimit) к качающему уходил в менее приоритетный класс, если он (качающий) начал занимать полосу сверх определенного лимита. Или, другими словами, более приоритетный класс должен "освобождаться" от трафика "качающего много" чтобы быть доступным (свободным) "качающим мало". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bomberman Опубликовано 17 мая, 2013 (изменено) · Жалоба Чудесная система какая то. Ну в прочем, вы в праве творить что хотите. Думаю в таком случае разумнее будет следить за тем, сколько по ремени "качающий" использует по максимуму свой менее приоритетный класс, и если это время превышает определённый лимит, то значит "ему нужно" и он отправляется в более быстрый класс. Ибо иначе как вы пймёте, что ему " это нужно"? А в сторону понижения приоритета, так же само. Изменено 17 мая, 2013 пользователем bomberman Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bos9 Опубликовано 17 мая, 2013 · Жалоба А чего тут чудесного? ) До недавнего времени очень востребованная схема. Но только средствами tc это не реализуется. Можно например раз в час создавать отчеты в биллинге по трафику каждого абонента и делить его на скорость по тарифу. Если этот коэффициент превысит некое определенное вами значение, то запускать скрипт, который перекинет качка в какой вам нужно класс. как то так... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
^rage^ Опубликовано 20 мая, 2013 · Жалоба connbytes/connrate в помощь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
voron Опубликовано 20 мая, 2013 · Жалоба connbytes/connrate в помощь.imho RATEEST+rateest лучше подойдёт, так как не привязан к conntrack-соединению. А для большого количества IP можно и нелинейные правила сделать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
