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

Question 1

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

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

Зачем мне вообще нужна кривая реального времени? Если предположить, что A1, A2, B1, B2 — это все 128 кбит/с link-share (нет кривой реального времени ни для одного из них), то каждый из них получит 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 кбит/с в режиме общего доступа? И если да, то в чем разница?

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

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

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

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

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

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

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

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

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

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

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

Это хорошее описание верхнего предела. Хотя описание link share строго точное, оно вводит в заблуждение. Хотя это правда, link share не дает жестких гарантий задержки, как это делает real time, он лучше справляется с предоставлением классу его полосы пропускания его распределения, чем его конкуренты, такие как CBQ и HTB. Поэтому, говоря, что link share "не дает гарантий", он удерживает его на более высоком стандарте, чем любой другой планировщик.

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

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

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

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

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

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

Answer

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

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

Зачем мне вообще нужна кривая реального времени? Если предположить, что A1, A2, B1, B2 — это все 128 кбит/с link-share (нет кривой реального времени ни для одного из них), то каждый из них получит 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 кбит/с в режиме общего доступа? И если да, то в чем разница?

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

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

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

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

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

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

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

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

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

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

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

Это хорошее описание верхнего предела. Хотя описание link share строго точное, оно вводит в заблуждение. Хотя это правда, link share не дает жестких гарантий задержки, как это делает real time, он лучше справляется с предоставлением классу его полосы пропускания его распределения, чем его конкуренты, такие как CBQ и HTB. Поэтому, говоря, что link share "не дает гарантий", он удерживает его на более высоком стандарте, чем любой другой планировщик.

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

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

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

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

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

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

Question 2

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

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

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

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

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

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

Если поток не выходит за границы определения link-share класса, то кривая реального времени никогда не используется. Определение кривой реального времени в этом случае позволяет вам, например: гарантировать определенный 'dmax'.

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

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

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

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

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

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

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

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

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

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

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

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

Это верно.

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

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

Answer

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

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

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

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

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

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

Если поток не выходит за границы определения link-share класса, то кривая реального времени никогда не используется. Определение кривой реального времени в этом случае позволяет вам, например: гарантировать определенный 'dmax'.

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

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

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

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

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

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

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

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

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

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

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

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

Это верно.

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

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

Question 3

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

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

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

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

Answer

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

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

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

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

Question 4

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

перейдите в исходный код ядра Linux и найдите файлы C, которые реализуют «фреймворк планирования TC»
Посмотрите заголовок и найдите автора кода.
Напишите электронное письмо программистам «TC scheduling framework» с просьбой предоставить литературу по их реализации.

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

Answer

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

перейдите в исходный код ядра Linux и найдите файлы C, которые реализуют «фреймворк планирования TC»
Посмотрите заголовок и найдите автора кода.
Напишите электронное письмо программистам «TC scheduling framework» с просьбой предоставить литературу по их реализации.

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

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

решение1

решение2

решение3

решение4

Связанный контент