В настоящее время я изучаю возможность использования сервера Ubuntu для обеспечения QoS вместо маршрутизатора потребительского класса. Я читал много ресурсов о tc и дисциплины очередей HTB - которые, похоже, являются тем, что мне нужно для моих потребностей в QoS, и даже если сейчас это в основном кажется ясным, все же есть что-то, что меня беспокоит с частотой подклассов.
Давайте посмотрим на этот образец конфигурации, найденный как ответ на этот вопрос :
tc class add dev eth0 parent 1: classid 1:1 htb rate 90kbps ceil 90kbps
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 30kbps ceil 60kbps
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 30kbps ceil 60kbps
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 30kbps ceil 60kbps
Это очень просто, если вы знаете, как tc работает: всем трем подклассам гарантирована пропускная способность 30 кбит / с, но разрешено заимствовать еще 30 кбит / с доступной полосы пропускания у своего родительского класса (30 + 30 = 60 кбит / с ceil).
Этот пример мне понятен. Общая пропускная способность родительского класса составляет 90 кбит / с, и каждому из трех подклассов гарантируется 30 кбит / с - 3 x 30 кбит / с = 90 кбит / с.
Теперь давайте посмотрим на этот другой пример из этого руководство :
# tc class add dev eth0 parent 1: classid 1:1 htb rate 6mbit burst 15k
# tc class add dev eth0 parent 1:1 classid 1:10 htb rate 5mbit burst 15k
# tc class add dev eth0 parent 1:1 classid 1:20 htb rate 3mbit ceil 6mbit burst 15k
# tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1kbit ceil 6mbit burst 15k
Вот где меня все запутывает. Первому подклассу гарантируется пропускная способность 5 Мбит, а второму - 3 Мбит. Но у родительского класса пропускная способность всего 6 Мбит!
Какова цель такого правила? Ни один из подклассов никогда не сможет получить свою гарантированную пропускную способность.
Еще более запутанным является вывод учебника:
HTB, безусловно, выглядит великолепно - если 10: и 20: у обоих есть гарантированная пропускная способность, а еще остается разделить больше, они занимают в соотношении 5: 3, как и следовало ожидать.
Откуда у обоих классов гарантированная пропускная способность? и у их родителей все еще есть пропускная способность?
Без сомнения, я кое-что упустил. Это могло быть некорректное руководство, но я нашел много других примеров с такими же запутанными настройками - Вот например :
/sbin/tc class add dev eth3 parent 1: classid 1:1 htb rate 2000kbit
/sbin/tc class add dev eth3 parent 1:1 classid 1:10 htb prio 1 rate 1500kbit ceil 1950kbit
/sbin/tc class add dev eth3 parent 1:1 classid 1:20 htb prio 2 rate 500kbit ceil 1600kbit
В этой конфигурации класс 1:20 сможет заимствовать полосу пропускания родительскому классу (разрешено заимствовать до 1600 Кбит), поскольку гарантированная пропускная способность его родного брата составляет 1500 Кбит - и 1500 Кбит своего брата плюс 500 Кбит его собственная гарантированная пропускная способность уже соответствует родительской пропускной способности 2000 кбит.
Может кто проясняет ситуацию?
Вы все-таки поняли, как работает htb.
Хотя вам нужно присмотреться к своим примерам: оба родительских класса не имеют ceil вариант, а затем будет использовать большую пропускную способность, если она доступна. Если в последнем примере родительский класс имел rate 2000kbit ceil 2000kbit, дочерний класс не сможет занять такую большую полосу пропускания.
Однако я согласен с тем, что в примере 5 + 3 Мбит оба класса не будут иметь гарантированной пропускной способности, если пропускная способность превышает 6 Мбит.
Вероятно, это ошибка.