О hfsc параметрах

На man-странице tc-hfsc(8) просто описывается синтаксис командной строки, но даже для этой простой задачи она оказывается неполной. tc-hfsc(7) - хорошее резюме оригинальной статьи, но, как и оригинальная статья, она не помогает новичкам, пытающимся получить интуитивное представление о том, что делает HFSC. Другими словами, не вините себя, официальная документация действительно плохая.

Попробуй прочитать это: http://linux-tc-notes.sourceforge.net/tc/doc/sch_hfsc.txt

Ответы на ваши конкретные вопросы. Он утверждает, что получает преимущество в 78мс по сравнению с задержкой, если посылает пакет 1500 VOIP на 400кбит, а не на 100кбит. Под кривой реального времени, 1500 байт VOIP пакета будет отправлен, как только линия станет бесплатной И кривая обслуживания VOIP говорит, что он заработал 1500 байт времени передачи. Задержка - это максимальное время между получением пакета и завершением отправки последнего байта.

= Time_to_earn_credit + Time_to_send_VOIP_packet

Время_до_отправки_VOIP_пакета составляет 12 мс:

= 1500 [byte] * 8 [bits/byte] / 1000000 [seconds]

Время_до_извлечения_кредита для отправки VOIP-пакета зависит от его разрешенного тарифа. При 100 кбит это 120мс:

= 1500 [byte] * 8 [bits/byte] / 100000 [seconds]

Аналогично, пакет Time_to_earn_credit при 400 кбит равен 1/4 от этого, или 30мс. Разница между этими двумя задержками составляет 80мс:

= (120ms + 12ms) - (30ms + 12ms)

Другими словами, учитывая факты, изложенные в его заявлении, он получает преимущество в 78мс - это неправильно. Это должно быть 80мс. Обратите внимание, что в своей диаграмме под текстом, который вы цитируете, он подтверждает это. Там он показывает, что разница составляет (120 мс - 30 мс) = 80 мс.

Далее он утверждает, что разрыв, предоставленный VOIP, увеличил задержку, когда данные пользователя А начинают посылать с 30 мс до 52,5 мс. Предположим, что ситуация, о которой он говорит, это VOIP и User Data A, которые ставят в очередь пакет размером с MTU в момент времени 0. Выше мы видели, что Time_to_earn_credit для отправки данных User A Data на 400kbit действительно составляет 30мс.

С дополнительным всплеском 300кбит (= 400кбит - 100кбит), выданным VOIP, должен быть какой-то другой класс, который снижает скорость на те же 300кбит, в противном случае ссылка будет перегружена. Мы не можем сказать, что он хотел по командам внизу, потому что, как мы увидим, они просто неправильные (они перекоммитировали ссылку). Но я угадаю и предположу, что она исходит от Пользователя A Data. Так что он должен упасть до 100 кбит за 30 мс, а затем вернуться к 400 кбит. Это делает вычисление Time_to_earn_credit для комплекса User A Data. Становится 52.5 мс:

= 30ms + ((1500 [bytes] * 8 [bits/byte] - Data_sent_in_30ms) / 400000 [bits/sec]
= 30ms + (12000 [bit] - 0.03 [sec] * 100000 [bytes/sec]) / 400000 [bits/sec]
= 30ms + (12000 [bit] - 3000 [bit]) / 400000 [bits/sec]
= 30ms + 22.5ms
= 52.5ms

Так что это утверждение действительно верно - оно действительно прошло с 30 мс до 52.5 мс. Он переходит к обсуждению того, как работает виртуальное время (а это неплохое описание).

Наконец, дается спецификация. Вот соответствующий бит для User A Data и VOIP:

classid 1:11 hfsc sc umax 1500b dmax 53ms rate 400kbit ul rate 1000kbit
classid 1:12 hfsc sc umax 1500b dmax 30ms rate 100kbit ul rate 1000kbit 

На данный момент нам нужно понять, как работают umax и dmax. Тогда tc-hfsc(8) описывает альтернативный синтаксис, а именно:

m1 BURST-RATE d BURST-SEC m2 STEADY-RATE

Что означает, что вы получаете BURST-RATE для BURST-SEC, а затем STEADY-RATE после этого. Человеческая страница затем продолжает говорить:

Очевидно, что m1 просто umax /max.

Не говорится, поэтому предположим, что dmax имеет то же значение, что и d. (Хорошее предположение - так говорит и исходный текст tc.) Его код гарантирует VOIP скорость взрыва 400 кбит:

= 1500 [bytes] * 8 [bits/byte] / 0.03 [seconds]

Таким образом, он дал VOIP 400 кбит за 30 мс, что именно то, что он имел в виду. Но, его код гарантирует Пользователю A Data burst-скорость около 226kbit:

= 1500 [bytes] * 8 [bits/sec] / 0.053 [seconds]

Обратите внимание, что общее количество 626kbit (= 226kbit + 400kbit) превышает то, что он хотел дать Пользователю A (500 kbit). Также обратите внимание, что он гарантировал Пользователю Б 500 кбит. Таким образом, по этому упрощенному сценарию он гарантировал в общей сложности 1126 кбит (=626 кбит + 500 кбит) по 1000 кбитному линку. Очевидно, что это не сработает.

К сожалению umax/dmax не делает того, что написано на man-странице. Как вы увидите, они настолько сложны, что только их мать может любить их. Мы, простые смертные, должны использовать альтернативный синтаксис "m1 ... d ... m2 ..." вместо этого. Однако Патрик МакГарди является их матерью, так что, возможно, он знал, что делает.

Синтаксис umax dmax rate делает очевидным только в том случае, если результирующая скорость взрыва превышает скорость, выделенную на rate. Для VOIP 226kbit действительно превышает 100kbit, так что это нормально. Для User A Data 226kbit она не превышает 400kbit, поэтому вещь dmax...umax на самом деле означает скорость взрыва 0(!) за 23 миллисекунды. 23 миллисекунды происходят из этого вычисления (взятого из исходных кодов tc, в q_hfsc.c):

= 53 - Time_to_send_MTU_at_*rate*
= 53 - 30

К сожалению, это не исправляет ссылку поверх коммита. Теперь он совершил коммит VOIP на burst 400kbit за 30 мс, а через 23 мс User A Data тоже получает 400kbit, так что за 7 мс там (=30 мс - 23 мс) пользователю A гарантировано 800kbit (=400kbit VOIP + 400kbit User A Data), а пользователю B гарантировано 500kbit, так что он гарантирован 1300kbit (=800kbit + 500kbit) на 1000kbit ссылке. Таким образом, доказав, что даже изобретатель dmax...umax не может корректно их использовать.

Если я правильно понимаю его намерения, то это сделает то, что он хотел:

tc qdisc add dev eth0 root handle 1: hfsc
tc class add dev eth0 parent 1: classid 1:1 hfsc ls rate 1000kbit ul rate 1000kbit
tc class add dev eth0 parent 1:1 classid 1:10 hfsc ls rate 500kbit
tc class add dev eth0 parent 1:1 classid 1:20 hfsc ls rate 500kbit
tc class add dev eth0 parent 1:10 classid 1:11 hfsc ls m2 400kbit
tc class add dev eth0 parent 1:10 classid 1:12 hfsc rt m1 400kbit d 30ms m2  100kbit

Есть ряд изменений:

• Все бары ul бары, расположенные на вершине, исчезли. Остальные лишние.
• sc sc для внутренних узлов стали ls. sc устанавливает и rt, и ls, но внутренние узлы игнорируют rt.
• Sc sc для данных пользователя A был заменен на простой ls. Очевидно, что пользовательские данные A не нуждаются в каких-либо гарантиях запаздывания. Все остальное является переборщиком.
• scsc для VOIP стала rt. Нотация umax/dmax исчезла, потому что, как мы видели, она ненадежна. Так как она не имеет распределения ls, 100kbit также является максимумом - она никогда не получит больше, чем после взрыва. В ls не нужно выделять rt, так как rt берет то, что ему нужно, а ls получает остальное.

Если бы данные пользователя A были на самом деле чувствительны к задержкам (очевидно, что это не так), то строка стала бы:

tc class add dev eth0 parent 1:10 classid 1:11 hfsc sc m1 100kbit d 30ms m2 400kbit

Примечание sc используется здесь для установки как rt (для задержки), так и ls. Здесь должны быть ls, иначе он не получит долю неиспользованной емкости. Скорее всего, в rt нет необходимости, так как то, что называется User A Data, вероятно, не нуждается в жестких гарантиях латентности. Предоставление гарантий жесткой задержки является единственной причиной, по которой вы используете rt.

Обратите также внимание, что теперь тривиально проверить, что вы не перешли через фиксацию ссылки. Просто сложите все листы m1 и m2. В реальном времени соответствующие суммы должны быть ниже емкости ссылки. (Для разделения ссылок это не имеет значения.) Для d's, просто убедитесь, что все классы, которым предоставляется реальный разрыв, имеют d не больше, чем любой из классов, которые не имеют. В этом случае rt's (напомним, что sc также rt) m1 в сумме составляет 500 кбит, так что это хорошо. m2 добавляется к 500 кбит, так что это хорошо. И самый длинный быстрый всплеск d составляет 30 мс, и ни один другой медленный всплеск d не меньше этого, так что это хорошо.

Это заняло больше времени, чем я думал. Забрать: это не ты, официальная документация действительно отстой.