noserver

[Efendy]

у меня стойкое впечатление, что я занимаюсь тем, что никому не нужно. Ну тогда, хотя бы на словах скажите, вот вы (мелкие провайдеры) же вручную бывает прирезаетете какого-нить клиента? По каким критериям? Например, смотрите, что канал загружен, а чел качает что-то уже 2 часа подряд и при этом с начала месяца скачал уже 100 гиг. Какие у вас критерии? Или только у меня такие проблемы... Ну тогда скажите данные по своей сети, например, у меня на каждые 100 человек в месяц потребляют примерно 7 терабайт трафика. Это я им раздолье даю или норм?

[stix]

раздолье.
у нас процветает тирания и диктатура.

[goletsa]

у меня стойкое впечатление, что я занимаюсь тем, что никому не нужно. Ну тогда, хотя бы на словах скажите, вот вы (мелкие провайдеры) же вручную бывает прирезаетете какого-нить клиента? По каким критериям? Например, смотрите, что канал загружен, а чел качает что-то уже 2 часа подряд и при этом с начала месяца скачал уже 100 гиг. Какие у вас критерии? Или только у меня такие проблемы... Ну тогда скажите данные по своей сети, например, у меня на каждые 100 человек в месяц потребляют примерно 7 терабайт трафика. Это я им раздолье даю или норм?

Например после сканичания n сотен Гб за месяц применяется политика что в часы наибольшей нагрузки такому юзеру скорость гдето в 5-10 раз может обрезаться.

[Efendy]

Например после сканичания n сотен Гб за месяц применяется политика что в часы наибольшей нагрузки такому юзеру скорость гдето в 5-10 раз может обрезаться.

в начале месяца это плохо работает

[Efendy]

Я вот думаю поступать так. Выделяется пайп, в который попадают разные проштрафившиеся. Причем размер пайпа динамический. Например, проштрафилось 3 клиента  с суммарным каналом в 15 мбит, пускаем их через один пайп в 10 мбит. Попал еще один клиент, скажем, с пакетом в 4 мбита, общий пайп сделали в 12 мбит. Числа от балды, но вот хотелось бы на словах алгоритмик. Тока реально продуманный.

[ser970]

Я вот думаю поступать так. Выделяется пайп, в который попадают разные проштрафившиеся. Причем размер пайпа динамический. Например, проштрафилось 3 клиента  с суммарным каналом в 15 мбит, пускаем их через один пайп в 10 мбит. Попал еще один клиент, скажем, с пакетом в 4 мбита, общий пайп сделали в 12 мбит. Числа от балды, но вот хотелось бы на словах алгоритмик. Тока реально продуманный.

у меня когда работало так ( я уже раньше писал )
при максиальной нагрузке резалось на скажем на 1% от трафика всем если канал еще забит то еще -1% до тех пор пока канал не разгрузится до 85%  от ширины  если меее 80% то обратный порядок
не поверите иногда на 2-3% обрезать скорость спасало. ( а клиент даже не ощущал что его режут). подумаешь вместо 1м получал 0.8м = а на общем сказывалось не хило. это реально работало.

[Efendy]

Резку трафика можно оформить и как справедливое явление, достаточно в часы НЕ пик повышать скорость тем, кому ранее резали. Клиенту объяснять: скорость может варьироваться - быть меньше и БОЛЬШЕ, но в среднем будет ваш тариф. Просто нужно понимать, что есть клиенты, которым важно скачать что-то, а есть пи..сы, которым важно качать неважно что. Главное требование к алгоритму - не трогать обычных клиентов, вплоть до того, что у наглых отбирать канал, даже если они мало его используют. Должен быть какой-то коэффициент "наглости", который в основном должен вычисляться динамически, но может модифицироваться и вручную (клиент постоянно нервы мотает). Живя в этом мире, я вижу как наглые получают свое, я не хочу этому способствовать. Почему клиент, который никогда не наглеет, не спорит и платит вовремя, решил скачать 2 фильма в один из 30 дней должен страдать от другого, который 29 дней качал под 100%, но в этот момент использует 50% своего тарифа, но тем не менее сейчас час пик и канал загружен под 100%. Честно слово, запарило выслушивать претензии от сотнегигокачальщиков, потому что они, с..ки, знают, что наглость - это 2е счастье. А я хочу доказать обратное)

[ser970]

я не умею объяснять, но попробую ,то что хотел сказать.

есть канал 100м. 120зверей (онлайн) по 1м и 4 наглых тоже по 1м
что даст если мы даже вырубим этих 4 в суме разгрузим канал на 4м .так ведь?  120м -4м > 100м
(ну это образно)
теперь порежем всех 120  на 20%  ( звери даже не почуствуют  1м или 0.8м (реально так глубоко не резалось))
120м - 20% < 100м. ведь так?
это реально работало

[Rico-X]

Мне кажется это перегрузка биллинга лишней логикой. Мы вообще отказались от использования шейперов, скорость клиента ограничена скоростью порта свича куда он воткнут. Я режу только nonUnicast трафик, остальное пусть укачаются. Столкнулся с ситуацией когда у нас уплоад значительно превышает даунлоад, локальный ретреккер обрабатывает огромное количество запросов, все новинки качаются внутри локалки. Было тяжело недели 2, подпирали полку, потом нагрузка как-то сама собой нормализовалась (у качальщиков похоже винты кончились). Не скажу что проблем нет, есть с отдельными свичами, по каждому порту веду статистику, если значение с отдельного порта в месяц превышает определенное - даем мониторингу сигнал и желающему забэкапить весь интернет просто обрезаю скорость на порту, таких очень мало на 1000 пользователей 2-3 человека.
ИМХО при современных скоростях наращивать логику шейперов нет смысла.

[ser970]

все верно когда каналы в гигабит и зверей мешок.
а когда 80м на 300 чел? есть такие сети.
притом новая версия модульная - надо используешь - не надо нет .

[smallcms]

у меня стойкое впечатление, что я занимаюсь тем, что никому не нужно. Ну тогда, хотя бы на словах скажите, вот вы (мелкие провайдеры) же вручную бывает прирезаетете какого-нить клиента? По каким критериям? Например, смотрите, что канал загружен, а чел качает что-то уже 2 часа подряд и при этом с начала месяца скачал уже 100 гиг. Какие у вас критерии? Или только у меня такие проблемы... Ну тогда скажите данные по своей сети, например, у меня на каждые 100 человек в месяц потребляют примерно 7 терабайт трафика. Это я им раздолье даю или норм?

мигобид:

Код:

<time 0,1,17,18,19,20,21,22,23>1:50-1000:200-996:500-994:1000-980

потрахек на 4 Гб:

Код:

<time 0,1,17,18,19,20,21,22,23>1:50-3000:200-2900:500-2100:1000-2000
<time 9,10,11,12,13,14,15,16>1:50-3000:200-2900:500-2700:1000-2600

Это уже реализованный динамический шейпер из 49.32. Из того, чего ужасно не хватало и будет нехватать "провайдерам"-мелочи - это конечно же раздельные шейпы на вход/выход каждого из направлений.
Ну и если бы оно отталкивалось не от полуночи, а как-то плавало постоянно и к вечеру приминяло доп. правила - вообще мечта юного инторнатчика была б...

[Efendy]

Я сам использую такой вариант, но он плох т.к. создает иллюзию хуевого инета - ночью клиент спит, его торент работает и выгребает свой канал на 100%. Вечером он по трафику попал в шейп, смотрит на показатели, а там скорость в 2 раза меньше. Какой вывод делает этот уродец? А то, что мы - уроды даем ему в 2 раза меньше заявленной скорости, хотя выгреб трафика на пару десятков обычных клиентов

Вариант 2: запускает торрент в 18-00 в начало часа пик. Нагружает общий канал, а шейпер его не режет т.к лимит не выгреб. Лучше остальным клиентам? Нифига.

Все это полумеры. Нужно рассматривать все в комплексе. Во-первых, трафик клиента за последние x-дней, включая за прошлый месяц, т.к. в первых числах трафик у всех малый. Во-вторых, общую загруженность канала.  В-третьих, среднюю загрузку за последний интервал времени Y.

Второй момент - как именно резать. Как вы уже поняли, вот тут я в поиске. Такой вариант: на основании текущих данных, делим клиентов на хороших и плохих (это деление условное и в данный конкретный момент времени). Канал у нас  A мбит. Хороших запускаем в канал B, плохих - в C. При этом A=B+C. Но! Не факт что B будет > C. На самом деле это будет высчитываться динамически. Граница может плавать пока не наступят самые лучшие показатели.

[Redmen]

мне нравитса етот вариант

у меня когда работало так ( я уже раньше писал )
при максиальной нагрузке резалось на скажем на 1% от трафика всем если канал еще забит то еще -1% до тех пор пока канал не разгрузится до 85%  от ширины  если меее 80% то обратный порядок
не поверите иногда на 2-3% обрезать скорость спасало. ( а клиент даже не ощущал что его режут). подумаешь вместо 1м получал 0.8м = а на общем сказывалось не хило. это реально работало.

[Efendy]

мне нравитса етот вариант

у меня когда работало так ( я уже раньше писал )
при максиальной нагрузке резалось на скажем на 1% от трафика всем если канал еще забит то еще -1% до тех пор пока канал не разгрузится до 85%  от ширины  если меее 80% то обратный порядок
не поверите иногда на 2-3% обрезать скорость спасало. ( а клиент даже не ощущал что его режут). подумаешь вместо 1м получал 0.8м = а на общем сказывалось не хило. это реально работало.

а в чем это отличается от варианта "никому не резать"? ведь цель не добиться загрузки канала менее 100%, а дать клиентам качественный инет. Ведь, если загрузка канала 100% - это хорошо, полная утилизация. Если вы забираете x% у каждого клиента, то почему за вас это не может делать физическое ограничение канала? Давайте считать. У вас канал 100 мбит. Клиенты качают по максимуму, в среднем абонент получает скорость 100/количество абонентов. Вы понижаете всем скорость до того момента, когда в среднем абонент получит скорость 99/количество абонентов? абсурд

Н.у. т.е уменьшением шейпов вы просто делаете работу, которую за вас бы сделал закон физики

[ser970]

а в чем это отличается от варианта "никому не резать"? ведь цель не добиться загрузки канала менее 100%, а дать клиентам качественный инет. Ведь, если загрузка канала 100% - это хорошо, полная утилизация.

отличается и сильно . загргузка канала 100% это конечно гуд - а что делать когда  уперлись в полочку  ?

Если вы забираете x% у каждого клиента, то почему за вас это не может делать физическое ограничение канала?

вот тут то и не может - один зверь запустил торент и выгреб ...

Давайте считать. У вас канал 100 мбит. Клиенты качают по максимуму, в среднем абонент получает скорость 100/количество абонентов. Вы понижаете всем скорость до того момента, когда в среднем абонент получит скорость 99/количество абонентов? абсурд
Н.у. т.е уменьшением шейпов вы просто делаете работу, которую за вас бы сделал закон физики

да можете проверить очень просто

сделайте общую трубу на два апи скажем по метру
и на одном компе запустите торен на другом веб ( что одинаково будет?)

тут принцып 0,1 копейки работает ( если округление в банке сдалать до 1коп = сумма получится не хилой = 92г.(по мойму)  )