Как мне выполнить настройку QoS, при которой определенный поток данных с низким приоритетом получит пропускную способность до X Мбит / с, но только если текущая общая пропускная способность (всех потоков / классов) на этом интерфейсе не превышает X? В то же время другие потоки / классы данных не должны ограничиваться X.
Пример использования - ISP выставление счетов за трафик путем расчета средней полосы пропускания за 5-минутные интервалы и выставления счетов по максимуму. Я хотел бы свести максимальное использование к минимуму (т.е. подавить массовую передачу во время занятости интерфейса), но передавать данные во время простоя / низкого трафика.
Глядя на часто используемые классные планировщики CBQ, HTB и HSFC, я не вижу простого способа добиться этого.
Я заставил это работать в hfsc. Я предполагаю, что "X" в вашем примере составляет 100 Мбит, но это может быть что угодно, конечно ..
Хитрость здесь в том, чтобы создать такой древовидный класс:
+--------------------------------------------------------------+ +---------------------+
| | | 1:1 |
| root | |---------------------|
| + | | Rate: 100mbit |
| | | | Upper Rate: 100mbit |
| | | | |
| | | | |
| | | | |
| +----v------+ | +---------------------+
| | 1:1 | |
| | | | +---------------------+
| +--+---+----+ | | 1:10 |
| | | | |---------------------|
| | | | | Rate: 100mbit |
| | | | | Upper Rate: 100mbit |
| | | | | |
| +----------+------+ +--------+----------+ | | |
| | 1:10 | | 1:11 | | | |
| | | | | | +---------------------+
| +----------+ +----------+ |
| | +---------------------+
| | | 1:11 |
| | |---------------------|
| | | Rate: 10kbit |
+--------------------------------------------------------------+ | Upper Rate: 100mbit |
| |
| |
| |
+---------------------+
Волшебство происходит потому, что класс 1:10 (класс по умолчанию) настроен так, чтобы всегда получать гарантированную пропускную способность 100 Мбит, тогда как «медленный» класс 1:11 предлагает гарантированную полосу пропускания всего 10 кбит с увеличением до 100 Мбит.
Это заставляет корневой класс (1: 1) всегда соблюдать требования 1:10 по 1:11.
На заметку:
Я тестировал это, когда два конкурирующих приложения отправляли данные как можно быстрее на соседний хост через 2 службы. Где одна из служб была в классе 1:11. Оба они отправили 5-секундный трафик на 100 Мбит (таким образом, 60 МБ данных было передано в потоке). При работе без класса, как и ожидалось, оба заканчивают работу через 10 секунд (оба используют ссылку, поэтому время делится поровну).
При такой настройке QoS приоритетное обслуживание завершается за 5 секунд, тогда как низкоприоритетное обслуживание завершается за 10 (как будто низкий приоритет ожидает завершения высокого приоритета первым), что, я думаю, именно то, что вам нужно.
Не уверен, что это сработает, но вы можете попробовать HTB:
rate к нулю (или почти нулю) и ceil к фактическому максимуму X. Это приводит к тому, что поток с низким приоритетом имеет гарантированную скорость, равную нулю, и вероятность заимствование максимум X Мбит / с из других потоков.Согласно Документация HTB, это должно сработать. Однако сам не пробовал.
РЕДАКТИРОВАТЬ: Это не будет ограничивать трафик с низким приоритетом, пока канал имеет пропускную способность в режиме ожидания X Мбит / с. Но это может быть начало ...
Это неудобно, но если вы можете вручную изменить предел, у вас может быть демон, усредняющий по более мелкой сетке (скажем, с интервалом в 1 минуту, отслеживающим последние 5-10). Тогда вам просто понадобится довольно простой контур управления, в котором вы настраиваете лимит трафика так, чтобы 5-минутное среднее значение оставалось безопасным ниже вашего лимита. Более сложные схемы прогнозирования трафика не обязательны.