Кто-нибудь действительно понимает, как работает планирование HFSC в Linux / BSD?

Я прочитал оригинальную статью SIGCOMM 'PostScript о HFSC, она очень технически, но я понимаю основную концепцию. Вместо того, чтобы давать линейную кривую обслуживания (как почти во всех других алгоритмах планирования), вы можете указать выпуклую или вогнутую кривую обслуживания, и, таким образом, можно разделить пропускную способность и задержку. Однако, хотя в этой статье упоминаются используемые алгоритмы планирования (в режиме реального времени и в общем канале), в нем всегда упоминается только ОДНА кривая на класс планирования (развязка выполняется путем указания этой кривой, для этого требуется только одна кривая). ).

Теперь HFSC был реализован для BSD (OpenBSD, FreeBSD и т. Д.) С использованием инфраструктуры планирования ALTQ, а также был реализован Linux с использованием инфраструктуры планирования TC (часть iproute2). Обе реализации добавили две дополнительные кривые обслуживания, которых не было в оригинальной статье! Кривая обслуживания в реальном времени и кривая обслуживания верхнего предела. Опять же, обратите внимание, что в оригинальной статье упоминаются два алгоритма планирования (в режиме реального времени и с разделением ссылок), но в этом документе оба работают с одной кривой обслуживания. Никогда не было двух независимых кривых обслуживания ни для одной из них, как в настоящее время вы найдете в BSD и Linux.

Хуже того, некоторые версии ALTQ, кажется, добавляют дополнительный приоритет очереди в HSFC (в оригинальной статье также нет такого понятия, как приоритет). Я обнаружил, что несколько BSD HowTo упоминают эту настройку приоритета (даже несмотря на то, что страница руководства последней версии ALTQ не знает такого параметра для HSFC, поэтому официально его даже не существует).

Все это делает планирование HFSC еще более сложным, чем алгоритм, описанный в оригинальной статье, и в Интернете существуют тонны учебных пособий, которые часто противоречат друг другу, одно из которых утверждает противоположность другого. Вероятно, это является основной причиной, почему никто не понимает, как на самом деле работает планирование HFSC. Прежде чем я смогу задать свои вопросы, нам нужен образец установки какого-то рода. Я буду использовать очень простой, как показано на рисунке ниже:

альтернативный текст http://f.imagehost.org/0177/hfsc-test-setup.png

Вот некоторые вопросы, на которые я не могу ответить, потому что учебники противоречат друг другу:

1. Зачем мне вообще нужна кривая в реальном времени? Если предположить, что A1, A2, B1, B2 - это общий канал связи 128 кбит / с (без кривой в реальном времени ни для одного из них), то каждый из них получит 128 кбит / с, если корень имеет 512 кбит / с для распределения (и A и B оба, конечно, 256 кбит / с), верно? Зачем мне дополнительно давать A1 и B1 кривую в реальном времени со 128 кбит / с? Для чего это будет хорошо? Чтобы дать этим двум более высокий приоритет? Исходя из оригинальной статьи, я могу придать им более высокий приоритет, используя кривую , в этом и заключается суть HFSC. Предоставляя обоим классам кривую [256 кбит / с, 20 мс, 128 кбит / с], оба имеют двойной приоритет автоматически, чем A2 и B2 (все еще получая в среднем только 128 кбит / с)

2. Учитывает ли пропускная способность в реальном времени пропускную способность канала связи? Например, если A1 и B1 имеют только 64 Кбит / с в режиме реального времени и 64 Кбит / с, то пропускная способность канала общего пользования означает, что это означает, что после того, как они обслуживаются 64 Кбит / с в режиме реального времени, их требования к каналу также будут выполнены (они могут получить избыточную пропускную способность, но давайте на секунду проигнорируем это) или это означает, что они получат еще 64 кбит / с через канал общего доступа? Так есть ли у каждого класса «требования» к пропускной способности в режиме реального времени плюс обмен ссылками? Либо класс имеет более высокое требование, чем кривая в реальном времени, если кривая доли канала выше, чем кривая реального времени (текущее требование доли канала равно заданному требованию доли канала минус полоса пропускания в реальном времени, уже предоставленная этому учебный класс)?

3. Применяется ли верхняя граничная кривая и к реальному времени, только к обмену ссылками или к обоим? Некоторые учебные пособия говорят одно, а другие - другое. Некоторые даже утверждают, что верхний предел - это максимальная пропускная способность в реальном времени + пропускная способность канала связи? Что правда?

4. Предполагая, что A2 и B2 равны 128 кбит / с, имеет ли какое-то значение, если A1 и B1 имеют только общий канал 128 кбит / с, или 64 кбит / с в реальном времени и 128 каналов кбит / с, и если да, какая разница?

5. Если я использую отдельную кривую в реальном времени для увеличения приоритетов классов, зачем мне вообще нужны «кривые»? Почему в режиме реального времени не является фиксированной стоимостью и обмен ссылками, а также фиксированной стоимостью? Почему обе кривые? Потребность в кривых очевидна в оригинальной статье, потому что в классе есть только один такой атрибут. Но теперь, имея три атрибута (в реальном времени, общий доступ к ссылкам и верхний предел), зачем мне все еще нужны кривые для каждого? Почему я хотел бы, чтобы форма кривых (не средняя полоса пропускания, а их наклоны) была разной для трафика в реальном времени и совместного использования каналов?

6. Согласно небольшой доступной документации, значения кривых в реальном времени полностью игнорируются для внутренних классов (классы A и B), они применяются только к листовым классам (A1, A2, B1, B2). Если это так, почему пример конфигурации ALTQ HFSC (поиск 3.3 Пример конфигурации ) устанавливает кривые в реальном времени для внутренних классов и утверждает, что они устанавливают гарантированную скорость этих внутренних классов? Разве это не совершенно бессмысленно? (примечание: pshare задает кривую разделения ссылок в ALTQ и создает кривую в реальном времени; вы можете увидеть это в параграфе выше примера конфигурации).

7. В некоторых руководствах говорится, что сумма всех кривых в реальном времени не может превышать 80% скорости линии, в других говорится, что она не должна превышать 70% скорости линии. Кто из них прав или они оба могут быть не правы?

8. Один учебник сказал, что вы забудете всю теорию. Независимо от того, как все работает на самом деле (планировщики и распределение пропускной способности), представьте три кривые в соответствии со следующей «упрощенной моделью мышления»: в реальном времени - это гарантированная пропускная способность, которую всегда будет получать этот класс. link-share - это пропускная способность, которую этот класс хочет полностью удовлетворить, но удовлетворение не может быть гарантировано. В случае избыточной пропускной способности класс может даже предложить больше пропускной способности, чем необходимо для удовлетворения, но он никогда не может использовать больше, чем указано в верхнем пределе. Чтобы все это работало, сумма всех полос пропускания в реальном времени не должна превышать хх% от скорости линии (см. Вопрос выше, процент варьируется). Вопрос: Является ли это более или менее точным или полным неправильным пониманием HSFC?

9. И если приведенные выше предположения действительно точны, то где в этой модели расстановка приоритетов? Например, у каждого класса может быть полоса пропускания в реальном времени (гарантированная), полоса пропускания общего канала связи (не гарантируется) и, возможно, верхний предел, но все же некоторые классы имеют более высокий приоритет, чем другие классы. В этом случае я все равно должен расставить приоритеты, даже среди трафика этих классов в реальном времени. Буду ли я расставлять приоритеты по наклону кривых? И если да, то какая кривая? Кривая в реальном времени? Кривая обмена ссылками? Кривая верхнего предела? Все они? Могу ли я дать им все один и тот же наклон или каждый по-разному, и как найти правильный наклон?

Я до сих пор не потерял надежду, что в этом мире существует, по крайней мере, множество людей, которые действительно понимают HFSC и способны точно ответить на все эти вопросы. И делать это, не противореча друг другу в ответах, было бы очень приятно ;-)

Чтение газет о HFSC и его двоюродных братьях не является хорошим способом понять это. Основная цель статьи HFSC - предоставить строгое математическое доказательство своих утверждений, не объясняя, как это работает. В самом деле, вы не можете понять, как это работает, только на бумаге HFSC, вы должны также прочитать статьи, на которые она ссылается. Если у вас есть какие-либо проблемы с претензией или ее доказательствами, то, возможно, хорошей идеей будет связаться с авторами документов, в противном случае я сомневаюсь, что они будут заинтересованы в получении от вас информации.

Я написал учебник для HFSC . Прочтите его, если мои объяснения ниже не ясны.

Зачем мне вообще нужна кривая в реальном времени? Если предположить, что A1, A2, B1, B2 - это общий канал связи 128 кбит / с (без кривой в реальном времени ни для одного из них), то каждый из них получит 128 кбит / с, если корень имеет 512 кбит / с для распределения (и A и B оба, конечно, 256 кбит / с), верно? Зачем мне дополнительно давать A1 и B1 кривую в реальном времени со 128 кбит / с? Для чего это будет хорошо? Чтобы дать этим двум более высокий приоритет? Исходя из оригинальной статьи, я могу придать им более высокий приоритет, используя кривую, в этом и заключается суть HFSC. Предоставляя обоим классам кривую [256 кбит / с, 20 мс, 128 кбит / с], оба имеют двойной приоритет автоматически, чем A2 и B2 (все еще получая в среднем только 128 кбит / с)

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

Совместное использование ссылок справедливо в том смысле, что оно не наказывает класс за использование свободной пропускной способности. Однако это означает, что он не может обеспечить надежные гарантии задержки.

Разделение общего доступа к ссылкам от предоставления гарантий задержки является новой вещью, которую HFSC приносит в таблицу, и в документе говорится так же во вступительном предложении: в этой статье мы изучаем иерархические модели и алгоритмы управления ресурсами, которые поддерживают как совместное использование ссылок, так и гарантированные услуги реального времени с несвязанной задержкой (приоритетом) и распределением полосы пропускания. Ключевое слово в этом предложении отделено. В переводе это означает, что вы, как ожидается, скажете, как неиспользованная полоса пропускания должна использоваться совместно с ls, и укажите, какие гарантии реального времени (или гарантии задержки) необходимы для rt. Два ортогональны.

Учитывает ли пропускная способность в реальном времени пропускную способность канала связи?

Да. В документе HFSC они определяют пропускную способность в терминах того, что класс отправил, так как класс стал засоренным (то есть имеет пакеты, ожидающие отправки). Единственное различие между rt и ls - это то, что rt смотрит вперед с каждым разом, когда класс был заблокирован, и вычисляет самую низкую гарантированную полосу пропускания из этого набора, тогда как совместное использование ссылок только смотрит с того момента, когда класс снова стал загруженным. Таким образом, rt учитывает больше байтов, чем ls, но каждый байт, который рассматривает ls, также считается rt.

Применяется ли верхняя граничная кривая и к реальному времени, только к обмену ссылками или к обоим?

Верхний предел не мешает отправке пакетов для удовлетворения условий реального времени. Пакеты, отправленные в режиме реального времени, все еще учитываются до верхнего предела и, таким образом, могут в будущем задержать отправку пакета при условии совместного использования канала. Это еще одно различие между реальным временем и общим доступом к ссылкам.

Предполагая, что A2 и B2 равны 128 кбит / с, имеет ли какое-либо значение, если A1 и B1 имеют только общий канал 128 кбит / с, или 64 кбит / с в реальном времени и 128 каналов кбит / с, и если да, какая разница?

Да, это имеет значение. Как объяснено выше, если вы используете реальное время, задержки гарантированы, но канал не распределяется справедливо (и, в частности, класс может страдать от истощения полосы пропускания), а верхние пределы не применяются. Если вы используете общий доступ к ссылкам, задержка не гарантируется, но общий доступ к ссылкам является справедливым, риск голодания отсутствует, а верхний предел применяется. Реальное время всегда проверяется перед передачей ссылки, однако это не обязательно означает, что ссылка будет игнорироваться. Это потому, что пакеты считаются по-разному. Поскольку история рассматривается в режиме реального времени, пакет, возможно, не требуется для обеспечения гарантии реального времени (из-за того, что подсчитано из истории), но необходим для удовлетворения общего ресурса канала, поскольку он игнорирует исторический пакет.

Если я использую отдельную кривую в реальном времени для увеличения приоритетов классов, зачем мне вообще нужны «кривые»? Почему в режиме реального времени не является фиксированной стоимостью и обмен ссылками, а также фиксированной стоимостью? Почему обе кривые? Потребность в кривых очевидна в оригинальной статье, потому что в классе есть только один такой атрибут. Но теперь, имея три атрибута (в реальном времени, общий доступ к ссылкам и верхний предел), зачем мне все еще нужны кривые для каждого? Почему я хотел бы, чтобы форма кривых (не средняя полоса пропускания, а их наклоны) была разной для трафика в реальном времени и совместного использования каналов?

Кривая для элементов управления в реальном времени позволяет вам торговать с высокой задержкой для одного конкретного класса трафика (например, VOIP) для плохой задержки для других классов трафика (например, электронной почты). При принятии решения, какой пакет отправить в режиме реального времени, HFSC выбирает тот, который завершит отправку первым. Однако он не использует пропускную способность канала для вычисления этого, он использует пропускную способность, выделенную кривой в реальном времени. Таким образом, если у нас есть пакеты VOIP и электронной почты одинаковой длины, а пакет VOIP имеет выпуклую кривую, которая дает увеличение в 10 раз по сравнению с вогнутой кривой для электронной почты, то 10 пакетов VOIP будут отправлены до первого пакета электронной почты. Но это происходит только в течение времени пакетной передачи, которое должно составлять самое большее время, необходимое для отправки нескольких пакетов, т.е. миллисекунд. После этого кривая VOIP должна сгладиться, и VOIP не получит дальнейшего повышения, если он не отступит на некоторое время (что, учитывая VOIP, является приложением с низкой пропускной способностью, должно быть). Конечным результатом всего этого является обеспечение того, что эти первые несколько пакетов VOIP отправляются быстрее, чем что-либо еще, что обеспечивает низкую задержку VOIP за счет высокой задержки электронной почты.

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

Согласно небольшой доступной документации, значения кривых в реальном времени полностью игнорируются для внутренних классов (классы A и B), они применяются только к листовым классам (A1, A2, B1, B2). Если это так, почему пример конфигурации ALTQ HFSC (поиск 3.3 Пример конфигурации) устанавливает кривые в реальном времени для внутренних классов и утверждает, что они устанавливают гарантированную скорость этих внутренних классов? Разве это не совершенно бессмысленно? (примечание: pshare задает кривую разделения ссылок в ALTQ и создает кривую в реальном времени; вы можете увидеть это в параграфе выше примера конфигурации).

Документация верна. Иерархия (и, следовательно, внутренние узлы) никак не влияет на вычисление в реальном времени. Я не могу сказать вам, почему ALTQ, очевидно, считает, что это так.

В некоторых руководствах говорится, что сумма всех кривых в реальном времени не может превышать 80% скорости линии, в других говорится, что она не должна превышать 70% скорости линии. Кто из них прав или они оба могут быть не правы?

Оба не правы. Если 70% или 80% вашего трафика предъявляют жесткие требования к задержке, которые необходимо указывать в режиме реального времени, реальность такова, что вы почти наверняка не сможете удовлетворить их с помощью ссылки, которую используете. Вам нужна более быстрая ссылка.

Единственный способ, которым кто-то может подумать, что 80% трафика должно быть в режиме реального времени, - это если они идут в режиме реального времени в качестве повышения приоритета. Да, для обеспечения гарантий задержки вы повышаете приоритет некоторых пакетов. Но это должно быть только за миллисекунды. Это все, с чем может справиться ссылка, и при этом предоставить гарантии задержки.

Существует очень мало трафика, который требует гарантий задержки. VOIP это один, NTP другой. Все остальное должно быть сделано с помощью обмена ссылками. Если вы хотите, чтобы сеть была быстрой, вы делаете это быстро, выделяя большую часть емкости ссылок. Эта доля будет гарантирована в течение длительного времени. Если вы хотите, чтобы это было с низкой задержкой (в среднем), дайте ему выпуклую кривую при совместном использовании ссылок.

Один учебник сказал, что вы забудете всю теорию. Независимо от того, как все работает на самом деле (планировщики и распределение пропускной способности), представьте три кривые в соответствии со следующей «упрощенной моделью мышления»: в реальном времени - это гарантированная пропускная способность, которую всегда будет получать этот класс. link-share - это пропускная способность, которую этот класс хочет полностью удовлетворить, но удовлетворение не может быть гарантировано. В случае избыточной пропускной способности класс может даже предложить больше пропускной способности, чем необходимо для удовлетворения, но он никогда не может использовать больше, чем указано в верхнем пределе. Чтобы все это работало, сумма всех полос пропускания в реальном времени не должна превышать хх% от скорости линии (см. Вопрос выше, процент варьируется). Вопрос: Является ли это более или менее точным или полным неправильным пониманием HSFC?

Это хорошее описание верхнего предела. Хотя описание ссылки на ссылку является строго точным, оно вводит в заблуждение. Несмотря на то, что это реальный общий доступ к каналам, он не дает жестких задержек, как в реальном времени, он лучше обеспечивает классу распределение пропускной способности, чем его конкуренты, такие как CBQ и HTB. Таким образом, говоря, что обмен ссылками «не дает гарантий», он удерживает его на более высоком уровне, чем любой другой планировщик.

Описание в реальном времени может быть точным, но вводящим в заблуждение, я бы назвал его неверным. Как следует из названия, цель реального времени - не дать гарантированную пропускную способность. Он предназначен для обеспечения гарантированной задержки - то есть пакет отправляется СЕЙЧАС, а не через какое-то случайное количество времени спустя, в зависимости от того, как используется канал. Большинству трафика не требуется гарантированная задержка.

Тем не менее, реальное время также не дает идеальных гарантий задержки. Это может произойти, если ссылка не управляется также с помощью общего ресурса, но большинство пользователей хотят иметь дополнительную гибкость, имея и то, и другое, и это не бесплатно. Реальное время может пропустить крайний срок задержки по времени, необходимому для отправки одного пакета MTU. (Если это произойдет, то это произойдет потому, что это произошло из-за доли канала передачи пакетов MTU, в то время как в режиме реального времени он оставался бездействующим в случае, если ему был предоставлен пакет с коротким сроком, который должен был быть отправлен немедленно. Это еще одно отличие между общим ресурсом канала и в режиме реального времени. Чтобы обеспечить свои гарантии, в режиме реального времени может намеренно поддерживать бездействие линии, даже если есть пакеты для отправки, что обеспечивает менее 100% использования канала. Доля канала всегда использует 100% доступной емкости канала. В отличие от реального времени ,

Можно сказать, что причина, по которой в режиме реального времени гарантированы жесткие задержки, заключается в том, что задержка ограничена. Таким образом, если вы пытаетесь предложить гарантированную задержку в 20 мс для канала со скоростью 1 Мбит / с, а общий ресурс канала отправляет пакеты размером MTU (1500 байт), вы знаете, что для отправки одного из этих пакетов потребуется 12 мс. Таким образом, если вы в режиме реального времени сообщаете, что хотите задержку в 8 мс, вы все равно можете уложиться в срок 20 мс - с абсолютной гарантией.

И если приведенные выше предположения действительно точны, то где в этой модели расстановка приоритетов? Например, у каждого класса может быть полоса пропускания в реальном времени (гарантированная), полоса пропускания общего канала связи (не гарантируется) и, возможно, верхний предел, но все же некоторые классы имеют более высокий приоритет, чем другие классы. В этом случае я все равно должен расставить приоритеты, даже среди трафика этих классов в реальном времени. Буду ли я расставлять приоритеты по наклону кривых? И если да, то какая кривая? Кривая в реальном времени? Кривая обмена ссылками? Кривая верхнего предела? Все они? Могу ли я дать им все один и тот же наклон или каждый по-разному, и как найти правильный наклон?

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

На самом деле никто не хочет такой расстановки приоритетов. То, что они хотят, - это то, что обеспечивает HFSC. Если у вас действительно есть трафик в реальном времени, HFSC обеспечит это. Но все будет напичкано. В остальном, HFSC позволяет вам сказать: «по перегруженной ссылке выделите 90% для веба, и пусть электронная почта наберется со скоростью 10%, и, о-о, отправьте нечетный DNS-пакет быстро, но не позволяйте кому-либо делать это с DOS».

Вы можете определить кривые с разными именами:

• RT, кривая в реальном времени, пропускная способность / задержка гарантия.
• ls, кривая совместного использования каналов, совместное использование полосы пропускания / задержки (на основе конфигурации соседних листьев)
• ul, кривая верхнего предела, максимальная полоса пропускания / задержка, которую она может достичь.

Зачем мне вообще нужна кривая в реальном времени? Если предположить, что A1, A2, B1, B2 - это общий канал связи 128 кбит / с (без кривой в реальном времени ни для одного из них), то каждый из них получит 128 кбит / с, если корень имеет 512 кбит / с для распределения (и A и B оба, конечно, 256 кбит / с), верно? Зачем мне дополнительно давать A1 и B1 кривую в реальном времени со 128 кбит / с? Для чего это будет хорошо? Чтобы дать этим двум более высокий приоритет? Исходя из оригинальной статьи, я могу придать им более высокий приоритет, используя кривую, в этом и заключается суть HFSC. Предоставляя обоим классам кривую [256 кбит / с, 20 мс, 128 кбит / с], оба имеют двойной приоритет автоматически, чем A2 и B2 (все еще получая в среднем только 128 кбит / с)

Когда вы делаете определение в HFSC только с тарифами, оно автоматически устанавливает 'dmax' в 0. Это означает, что оно не учитывает задержку. Хорошая конфигурация HFSC должна включать в себя как полосу пропускания, так и границы задержки, которые вы хотите использовать для своего класса, иначе алгоритм не может точно определить, какой приоритет должен получить класс.

Всякий раз, когда вы даете приоритет пакетам, другие пакеты должны быть уменьшены в приоритете. На основе значений 'dmax' и 'rate' все классы будут мультиплексированы с использованием виртуальных таймеров. Обратитесь к tc-hfsc (7) за дополнительной информацией.

Учитывает ли пропускная способность в реальном времени пропускную способность канала связи? Например, если A1 и B1 имеют только 64 кбит / с в режиме реального времени и 64 кбит / с с пропускной способностью канала связи, означает ли это, что когда они обслуживаются с пропускной способностью 64 кбит / с в режиме реального времени, их требования к каналу также выполняются (они могут получить избыточную пропускную способность, но давайте на секунду проигнорируем это) или это означает, что они получат еще 64 кбит / с через канал общего доступа? Так есть ли у каждого класса «требования» к пропускной способности в режиме реального времени плюс обмен ссылками? Или у класса есть только более высокое требование, чем у кривой реального времени, если кривая доли канала выше, чем кривая реального времени (текущее требование доли канала равно заданному требованию доли канала минус полоса пропускания в реальном времени, уже предоставленная этому учебный класс)?

Если поток не пересекает границы определения общего ресурса класса, тогда кривая в реальном времени никогда не используется. Определение кривой реального времени в этом случае позволяет вам, например: гарантировать определенный «dmax».

Если ваши определения обмена ссылками безупречны, то вам не понадобятся кривые в реальном времени. Вы можете просто определить кривые обслуживания (sc), но это усложнит вашу конфигурацию.

Применяется ли верхняя граничная кривая и к реальному времени, только к обмену ссылками или к обоим? Некоторые учебные пособия говорят одно, а другие - другое. Некоторые даже утверждают, что верхний предел - это максимальная пропускная способность в реальном времени + пропускная способность канала связи? Что правда?

Кривая верхнего предела вашего класса применяется только к общему обмену ссылками, когда вы определяете кривую верхнего предела, вы ДОЛЖНЫ определить кривую совместного использования ссылок. Однако кривая верхнего предела родительских классов все еще применяется.

Предполагая, что A2 и B2 равны 128 кбит / с, имеет ли какое-либо значение, если A1 и B1 имеют только общий канал 128 кбит / с, или 64 кбит / с в реальном времени и 128 каналов кбит / с, и если да, какая разница?

Существует небольшая разница, если, например, A2 = 0 кбит / с и B2 = 256 кбит / с. Тогда виртуальное время для А2 будет на максимуме. Всякий раз, когда пакеты классифицируются в A2, они будут немедленно обработаны. Однако кривая В2 в реальном времени все еще гарантирует, что она способна передавать по крайней мере 64 кбит / с.

Если я использую отдельную кривую в реальном времени для увеличения приоритетов классов, зачем мне вообще нужны «кривые»? Почему в режиме реального времени не является фиксированной стоимостью и обмен ссылками, а также фиксированной стоимостью? Почему обе кривые? Потребность в кривых очевидна в оригинальной статье, потому что в классе есть только один такой атрибут. Но теперь, имея три атрибута (в реальном времени, общий доступ к ссылкам и верхний предел), зачем мне все еще нужны кривые для каждого? Почему я хотел бы, чтобы форма кривых (не средняя полоса пропускания, а их наклоны) была разной для трафика в реальном времени и совместного использования каналов?

Кривые в реальном времени не делят трафик между соседними листьями, кривые совместного использования ссылок делают.

Согласно небольшой доступной документации, значения кривых в реальном времени полностью игнорируются для внутренних классов (классы A и B), они применяются только к листовым классам (A1, A2, B1, B2). Если это так, почему пример конфигурации ALTQ HFSC (поиск 3.3 Пример конфигурации) устанавливает кривые в реальном времени для внутренних классов и утверждает, что они устанавливают гарантированную скорость этих внутренних классов? Разве это не совершенно бессмысленно? (примечание: pshare задает кривую разделения ссылок в ALTQ и создает кривую в реальном времени; вы можете увидеть это в параграфе выше примера конфигурации).

Это правда, что кривые в реальном времени игнорируются для внутренних классов, они применяются только к листовым классам. Однако кривые в реальном времени, определенные для этих внутренних классов, принимаются во внимание для расчетов на листовых классах.

В некоторых руководствах говорится, что сумма всех кривых в реальном времени не может превышать 80% скорости линии, в других говорится, что она не должна превышать 70% скорости линии. Кто из них прав или они оба могут быть не правы?

Они имеют в виду следующее: вы не можете расставить приоритеты для всего трафика ... Всякий раз, когда вы даете приоритет пакетам, другим пакетам нужно уменьшать приоритет. Если вы чрезмерно гарантируете, алгоритм становится бессмысленным. Определите класс, который получает приоритеты, и определите классы, которые могут пострадать.

Один учебник сказал, что вы забудете всю теорию. Независимо от того, как все работает на самом деле (планировщики и распределение пропускной способности), представьте три кривые в соответствии со следующей «упрощенной моделью мышления»: в реальном времени - это гарантированная пропускная способность, которую всегда будет получать этот класс. link-share - это пропускная способность, которую этот класс хочет полностью удовлетворить, но удовлетворение не может быть гарантировано. В случае избыточной пропускной способности класс может даже предложить больше пропускной способности, чем необходимо для удовлетворения, но он никогда не может использовать больше, чем указано в верхнем пределе. Чтобы все это работало, сумма всех полос пропускания в реальном времени не должна превышать хх% от скорости линии (см. Вопрос выше, процент варьируется). Вопрос: Является ли это более или менее точным или полным неправильным пониманием HSFC?

Это верно.

И если приведенные выше предположения действительно точны, то где в этой модели расстановка приоритетов? Например, у каждого класса может быть полоса пропускания в реальном времени (гарантированная), полоса пропускания общего канала связи (не гарантируется) и, возможно, верхний предел, но все же некоторые классы имеют более высокий приоритет, чем другие классы. В этом случае я все равно должен расставить приоритеты, даже среди трафика этих классов в реальном времени. Буду ли я расставлять приоритеты по наклону кривых? И если да, то какая кривая? Кривая в реальном времени? Кривая обмена ссылками? Кривая верхнего предела? Все они? Могу ли я дать им все один и тот же наклон или каждый по-разному, и как найти правильный наклон?

Разница между, например, HFSC и HTB заключается в том, что HFSC позволит вам точно определить, какой приоритет вы хотите иметь. Вы делаете это, определяя минимальные и максимальные границы значением 'dmax'.

Наконец, руководство, которое, кажется, объясняет большинство несоответствий, а также, как текущая реализация отличается от оригинальной статьи:

http://manpages.ubuntu.com/manpages/precise/man7/tc-hfsc.7.html

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

Я думаю, что я, наконец, откажусь от HFSC. Если вы можете правильно настроить HFSC, это может быть лучшим QoS, которое вы можете получить, но шансы, что вы полностью испортите, намного выше, чем шансы на ваш успех.

Если вы не можете заполучить оригинальных авторов, я бы попробовал следующее:

1. зайдите в дерево исходных текстов ядра Linux и найдите C-файлы, которые реализуют «структуру планирования TC»
2. Посмотрите на заголовок и найдите автора кода.
3. Электронная почта программистов "TC scheduling framework" просит у них литературу по их реализации.

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