Мы подготовили документацию по новой опции Token Bucket — это новая, захватывающая и мощная функция для очередей и ограничения полосы пропускания. Подробная информация и пример настройки здесь: http://wiki.mikrotik.com/wiki/Manual:HTB-Token_Bucket_Algorithm Краткая схема, объясняющая алгоритм Token Bucket.
Потому что через 10 секунд вы заработаете ещё 100 миллионов токенов. Потратить 100 миллионов токенов занимает всего 5 секунд при скорости 20M/с… НО за эти 5 секунд вы также заработаете ещё 50 миллионов токенов… Эти 50 миллионов потратить можно за 2,5 секунды, пока вы снова заработаете ещё 25 миллионов… и так далее.
Если нужна формула, то в целом она такая: Время опустошения/заполнения = absval(Размер бака * Скорость набора токенов / (Скорость данных - Скорость токенов))
Здесь время означает «заполнить с пустого» если скорость данных ниже скорости токенов, и «опустошить полный» если скорость данных больше скорости токенов. Если они равны, получится деление на ноль — так что этого лучше избегать.
Очевидно, эта формула предполагает глупость — постоянную скорость данных. В конечном итоге, правда, неправильно так думать — скорости данных почти никогда не бывают постоянными, и невозможно предсказать, будет ли поток «копить» токены или тратить их постоянно и т.д.
Размер корзины работает с неограниченными очередями? Или нужно устанавливать лимиты? Если нет, то это было бы очень полезно для работы с неограниченными очередями... так я думаю. Задать только время всплеска, остальные значения сделать неограниченными и брать корзины у родительского элемента, например. Работает ли это?
Разве на диаграмме не указано, что есть предельный уровень всплеска и максимальный предельный уровень всплеска, то есть они дают диапазон, а не что-то безлимитное?
Мы используем Simple Queues для каждого клиента, на некоторых Mikrotik’ах их по 400-500 штук. Вводим имя клиента, IP-адрес, затем на вкладке advanced выбираем PCQ, чтобы задать скорость загрузки и отдачи. В PCQ есть таймер burst, благодаря которому, например, скорость может подняться до 7 Мбит/с на 40 минут, а потом снизиться примерно до половины от burst — около 3-4 Мбит/с. После обновления прошивки мы заметили параметр «bucket size», который у всех стоит по умолчанию 0.100. Нужно ли его менять, чтобы всё работало точно так же, или default 0.100 никак не повлияет на текущие настройки?
Можешь, пожалуйста, привести пример, как использовать это на ADSL-соединении 20/1 и установить максимальный лимит 10 в одной из 8 очередей в simple queue? Какие значения что означают? Заранее спасибо.
Кто ещё не сделал? Отлично. Похоже, эта функция не работает, и вам просто стыдно в этом признаться. Ничего страшного, если она не работает. Просто кто-то должен написать что-нибудь, чтобы мы перестали тратить на это время.
Итак, учитывая все вышесказанное, если мы хотим настроить систему с минимальной импульсностью (у нас сеть дальше, которая контролирует трафик с интервалом в 10 мс!), на самом деле размер «ведра» должен быть не больше, чем для одного пакета (1500 байт). То есть при скорости 100 Мб размер «ведра» будет 0,00012 (0,00012*10000000/8 = 1500). Жаль, что нельзя указать размер напрямую (в байтах). Правильно?
Я только что понял, что на самом деле означает этот параметр. Это действительно «время заполнения ведра» — время, которое нужно, чтобы заполнить ведро с пустого состояния, когда пакеты не поступают. Количество секунд потока токенов (которое задаётся через max-limit/limit-at и так далее), которое может храниться там (после чего токены переполняются). Похоже, что у этого параметра есть нижний предел — 0.001, то есть 1 мс, что вполне подходит для наших целей.
Есть ли смысл играть с размером очереди (Queue bucket-size), чтобы справиться с DOS/DDOS и 100%-ной загрузкой процессора из-за ожидания? Если да, то как именно?
Время означает «заполнение из пустого», если скорость передачи данных ниже скорости токенов, и означает «опустошение из полного», если скорость передачи данных выше скорости токенов.
Всем привет! Я тут новичок, поэтому постараюсь объяснить свою проблему в терминологии ROS как можно точнее. Моя проблема — «призрачное» свойство queue tree/simple queues. Вчера я реально провел больше 12 часов, читая WIKI, мануалы, примерные скрипты и т.п., но так и не нашел, как сделать очень простую вещь: как задать значение «limit-at» выше, чем «max-limit». Кто-нибудь может просветить меня, чтобы я мог сказать: «Эх, я дурак», потому что иначе мое пока что хорошее мнение о программистах ROS сильно ухудшится.
Собственно, этот пост — главная причина, почему я решил присоединиться к форуму, и вот что мне не нравится: картинка ниже. В этом алгоритме он никогда не сработает, или я слепой. Решайте сами…
[admin@GoranmarGW] > /queue tree add name=test_queue max-limit=10M limit-at=20M parent=global failure: -max-limit less than -limit [admin@GoranmarGW] > И Mikrotik говорит:
Зачем вы хотите установить limit-at выше, чем max-limit? Max limit — максимальная пропускная способность, которую клиент может использовать; Limit at — минимальная пропускная способность, которая должна быть доступна клиенту, если одновременно есть несколько подключений от разных клиентов.
Я не согласен! Моя суть — огромная логическая ошибка в алгоритме. Но ирония в том, что очереди ведут себя почти так, как показано на диаграмме. За мои более чем 10 лет опыта с ROS, значение limit-at никогда не оказывало однозначного и предсказуемого влияния на поведение очереди. Похоже, что чего бы я ни хотел добиться с очередями, лучший способ — метод проб и ошибок, ведь документация вроде этой выше абсолютно не помогает. Жаль...