Я прочитал оригинал Бумага SIGCOMM '97 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
Вот некоторые вопросы, на которые я не могу ответить, потому что уроки противоречат друг другу:
Зачем вообще нужна кривая в реальном времени? Предполагая, что A1, A2, B1, B2 - это общий канал со скоростью 128 кбит / с (без кривой в реальном времени ни для одного из них), тогда каждый из них получит 128 кбит / с, если корень имеет 512 кбит / с для распределения (и A и B, конечно, 256 кбит / с), верно? Зачем мне дополнительно давать A1 и B1 кривую в реальном времени со скоростью 128 кбит / с? Для чего это было бы хорошо? Дать этим двоим больший приоритет? Согласно исходной статье, я могу дать им более высокий приоритет, используя кривая, в конце концов, это и есть HFSC. Задавая обоим классам кривую [256 кбит / с 20 мс 128 кбит / с], оба автоматически имеют в два раза больший приоритет, чем A2 и B2 (в среднем все еще получают только 128 кбит / с)
Учитывается ли пропускная способность в реальном времени при расчете пропускной способности канала обмена? Например. если A1 и B1 имеют пропускную способность только 64 Кбит / с в реальном времени и 64 Кбит / с, означает ли это, что после того, как они обслуживаются со скоростью 64 Кбит / с в режиме реального времени, их требования к обмену ссылками также удовлетворяются (они могут получить избыточная пропускная способность, но давайте проигнорируем это на секунду) или это означает, что они получают еще 64 кбит / с через link-share? Итак, есть ли у каждого класса «требования» к полосе пропускания в реальном времени плюс совместное использование ссылок? Или класс имеет более высокие требования, чем кривая реального времени, только если кривая доли ссылок выше, чем кривая реального времени (текущие требования к совместному использованию ссылок равны указанным требованиям к совместному использованию ссылок минус полоса пропускания в реальном времени, уже предоставленная этому классу). класс)?
Применяется ли кривая верхнего предела и к реальному времени, только для обмена ссылками, или, может быть, к обоим? В некоторых руководствах говорится об одном, в других - об обратном. Некоторые даже заявляют, что верхний предел - это максимум для полосы пропускания в реальном времени + пропускной способности канала обмена? Что правда?
Предполагая, что A2 и B2 имеют 128 кбит / с, имеет ли это какое-либо значение, если A1 и B1 имеют только общий доступ к каналу 128 кбит / с или 64 кбит / с в реальном времени и 128 кбит / с для обмена ссылками, и если да какая разница?
Если я использую отдельную кривую в реальном времени для увеличения приоритетов классов, зачем мне вообще нужны «кривые»? Почему в реальном времени не фиксируется фиксированная стоимость, а доля ссылок - также фиксированная стоимость? Почему обе кривые? Необходимость кривых очевидна в исходной статье, потому что в каждом классе есть только один атрибут такого типа. Но теперь, имея три атрибута (реальное время, общий доступ по ссылке и верхний предел), зачем мне все еще нужны кривые на каждом из них? Зачем мне кривые форма (не средняя пропускная способность, а их наклоны), чтобы они были разными для трафика в реальном времени и трафика обмена ссылками?
Согласно небольшой доступной документации, значения кривой в реальном времени полностью игнорируются для внутренних классов (класс A и B), они применяются только к конечным классам (A1, A2, B1, B2). Если это правда, почему Пример конфигурации ALTQ HFSC (ищи 3.3 Пример конфигурации) устанавливает кривые в реальном времени для внутренних классов и утверждает, что они устанавливают гарантированную скорость этих внутренних классов? Разве это не бессмысленно? (примечание: pshare устанавливает кривую доли ссылок в ALTQ и рисует кривую в реальном времени; вы можете увидеть это в абзаце над примером конфигурации).
В некоторых руководствах говорится, что сумма всех кривых в реальном времени не может превышать 80% линейной скорости, другие говорят, что она не должна превышать 70% скорости линии. Какой из них правильный, или они оба ошибаются?
В одном руководстве говорилось, что вы забудете всю теорию. Независимо от того, как все работает на самом деле (планировщики и распределение полосы пропускания), представьте себе три кривые в соответствии со следующей «упрощенной моделью разума»: в реальном времени - это гарантированная пропускная способность, которую этот класс всегда будет получать. link-share - это пропускная способность, которую этот класс хочет полностью удовлетворить, но удовлетворение не может быть гарантировано. В случае избыточной пропускной способности классу может быть даже предложена пропускная способность больше, чем необходимо для удовлетворения требований, но он никогда не может использовать больше, чем указано в верхнем пределе. Чтобы все это работало, сумма всех полос пропускания в реальном времени не должна превышать xx% от скорости линии (см. Вопрос выше, процент варьируется). Вопрос: Это более-менее верно или полное непонимание HSFC?
И если вышеприведенное предположение действительно верно, то где в этой модели расстановка приоритетов? Например. каждый класс может иметь полосу пропускания в реальном времени (гарантированную), полосу пропускания общего доступа (не гарантированную) и, возможно, верхний предел, но все же некоторые классы имеют более высокий приоритет, чем другие классы. В этом случае я все равно должен каким-то образом расставить приоритеты, даже среди трафика в реальном времени этих классов. Могу ли я расставить приоритеты по наклону кривых? И если да, то какой кривой? Кривая в реальном времени? Кривая доли ссылки? Кривая верхнего предела? Все они? Могу ли я дать им всем одинаковый уклон или каждому свой, и как найти правильный уклон?
Я до сих пор не теряю надежды на то, что в этом мире существует хотя бы горстка людей, которые действительно понимают 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 - это пропускная способность, которую этот класс хочет полностью удовлетворить, но удовлетворение не может быть гарантировано. В случае избыточной пропускной способности классу может быть даже предложена пропускная способность больше, чем необходимо для удовлетворения требований, но он никогда не может использовать больше, чем указано в верхнем пределе. Чтобы все это работало, сумма всех полос пропускания в реальном времени не должна превышать xx% от скорости линии (см. Вопрос выше, процент варьируется). Вопрос: Это более-менее верно или полное непонимание HSFC?
Это хорошее описание верхнего предела. Хотя описание ссылки является строго точным, оно вводит в заблуждение. Хотя истинный обмен ссылками не дает жестких гарантий задержки, как в реальном времени, он лучше справляется с выделением пропускной способности класса, чем его конкуренты, такие как CBQ и HTB. Таким образом, говоря, что совместное использование ссылок «не дает гарантий», оно соответствует более высокому стандарту, чем может предоставить любой другой планировщик.
Описание в реальном времени может быть точным, но настолько вводящим в заблуждение, что я бы назвал его неправильным. Как следует из названия, цель реального времени не в обеспечении гарантированной пропускной способности. Это должно обеспечить гарантированную задержку - то есть пакет отправляется СЕЙЧАС, а не какое-то случайное количество времени позже, в зависимости от того, как используется ссылка. Для большинства трафика не требуется гарантированная задержка.
Тем не менее, реальное время также не дает идеальных гарантий задержки. Это могло бы быть, если бы ссылка также не управлялась с помощью общего ресурса ссылки, но большинство пользователей хотят дополнительной гибкости, имея и то, и другое, и это не предоставляется бесплатно. В режиме реального времени может пропустить крайний срок задержки к тому времени, которое требуется для отправки одного пакета MTU. (Если это произойдет, это произойдет из-за того, что это был общий ресурс связи пакета MTU, в то время как в режиме реального времени канал оставался незанятым в случае, если ему был дан пакет с коротким сроком, который нужно было отправить немедленно. Это еще одно различие между общим доступом канала и в реальном времени. Чтобы обеспечить свои гарантии, в режиме реального времени линия может преднамеренно оставаться в режиме ожидания, даже если есть пакеты для отправки, что обеспечивает менее 100% использования канала связи. Совместное использование канала всегда использует 100% доступной емкости каналов. В отличие от реального времени , можно сказать, что это «сберегает работу».)
Причина, по которой можно сказать, что реальное время предлагает жесткие гарантии задержки, заключается в том, что задержка ограничена. Итак, если вы пытаетесь предложить гарантию задержки 20 мс для канала со скоростью 1 Мбит / с, а общий ресурс ссылки отправляет пакеты размером с MTU (1500 байт), вы знаете, что для отправки одного из этих пакетов потребуется 12 мс. Таким образом, если вы скажете в реальном времени, что вам нужна задержка в 8 мс, вы все равно сможете уложиться в крайний срок в 20 мс - с абсолютной гарантией.
И если вышеприведенное предположение действительно верно, то где в этой модели расстановка приоритетов? Например. каждый класс может иметь полосу пропускания в реальном времени (гарантированную), полосу пропускания общего доступа (не гарантированную) и, возможно, верхний предел, но все же некоторые классы имеют более высокий приоритет, чем другие классы. В этом случае я все равно должен каким-то образом расставить приоритеты, даже среди трафика в реальном времени этих классов. Могу ли я расставить приоритеты по наклону кривых? И если да, то какой кривой? Кривая в реальном времени? Кривая доли ссылки? Кривая верхнего предела? Все они? Могу ли я дать им всем одинаковый уклон или каждому свой, и как определить правильный уклон?
Нет модели приоритезации. Шутки в сторону. Если вы хотите установить абсолютный приоритет трафика, используйте pfifo. Вот для чего это нужно. Но также имейте в виду, что если вы дадите веб-трафику абсолютный приоритет над трафиком электронной почты, это означает, что веб-трафик будет насыщать ссылку и, следовательно, пакеты электронной почты не будут проходить, вообще. Тогда все ваши почтовые соединения умрут.
На самом деле никто не хочет такой расстановки приоритетов. Они хотят то, что предоставляет HFSC. Если у вас действительно есть трафик в реальном времени, HFSC предоставляет это. Но это будет все хлам. В остальном, HFSC позволяет вам сказать «при перегруженном канале, выделить 90% для Интернета и позволить электронной почте просачиваться на 10%, и ох, быстро отправить нечетный пакет DNS, но не позволяйте кому-то DOS мне с ним».
Вы можете определить кривые с разными именами:
Зачем вообще нужна кривая в реальном времени? Предполагая, что 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 кбит / с через link-share? Итак, есть ли у каждого класса «требования» к полосе пропускания в реальном времени плюс совместное использование ссылок? Или класс имеет более высокие требования, чем кривая в реальном времени, только если кривая доли ссылок выше кривой в реальном времени (текущие требования к совместному использованию ссылок равны указанным требованиям к совместному использованию ссылок минус полоса пропускания в реальном времени, уже предоставленная для этого класс)?
Если поток не выходит за границы определения класса общего доступа к ссылкам, кривая реального времени никогда не используется. Определение кривой в реальном времени в этом случае позволяет, например: гарантировать определенный «dmax».
Если ваши определения совместного использования ссылок безупречны, тогда вам не понадобятся кривые в реальном времени. Вы можете просто определить кривые обслуживания (sc), но это усложнит вашу конфигурацию.
Применяется ли кривая верхнего предела и к реальному времени, только для обмена ссылками, или, может быть, к обоим? В некоторых руководствах говорится об одном, в других - об обратном. Некоторые даже заявляют, что верхний предел - это максимум для полосы пропускания в реальном времени + пропускной способности канала-обмена? Что правда?
Кривая верхнего предела вашего класса применяется только к обмену ссылками, когда вы определяете кривую верхнего предела, вы ДОЛЖНЫ определить кривую совместного использования ссылок. Однако кривая верхнего предела родительских классов все еще применяется.
Предполагая, что A2 и B2 имеют значение 128 кбит / с, имеет ли значение, если A1 и B1 имеют только общий канал связи 128 кбит / с или 64 кбит / с в режиме реального времени и 128 кбит / с с общим доступом, и если да какая разница?
Есть небольшая разница, например, если A2 = 0 кбит / с и B2 = 256 кбит / с. Тогда виртуальное время для A2 будет максимальным. Всякий раз, когда пакеты классифицируются в A2, они будут немедленно обработаны. Тем не менее, кривая B2 в реальном времени по-прежнему гарантирует, что скорость передачи данных составляет не менее 64 кбит / с.
Если я использую отдельную кривую в реальном времени для увеличения приоритетов классов, зачем мне вообще «кривые»? Почему в реальном времени не фиксируется фиксированная стоимость, а доля ссылок - также фиксированная стоимость? Почему обе кривые? Необходимость кривых очевидна в исходной статье, потому что в каждом классе есть только один атрибут такого типа. Но теперь, имея три атрибута (реальное время, общий доступ по ссылке и верхний предел), зачем мне все еще нужны кривые для каждого из них? Почему мне нужно, чтобы форма кривых (не средняя пропускная способность, а их наклон) отличалась для трафика реального времени и трафика обмена ссылками?
Кривые в реальном времени не распределяют трафик между соседними конечностями, в отличие от кривых распределения ссылок.
Согласно небольшой доступной документации, значения кривой в реальном времени полностью игнорируются для внутренних классов (класс A и B), они применяются только к конечным классам (A1, A2, B1, B2). Если это правда, то почему примерная конфигурация ALTQ HFSC (поиск 3.3 Пример конфигурации) устанавливает кривые в реальном времени для внутренних классов и утверждает, что они устанавливают гарантированную скорость этих внутренних классов? Разве это не бессмысленно? (примечание: pshare устанавливает кривую доли ссылок в ALTQ и рисует кривую в реальном времени; вы можете увидеть это в абзаце над примером конфигурации).
Это правда, что кривые реального времени игнорируются для внутренних классов, они применяются только к конечным классам. Однако кривые реального времени, определенные для этих внутренних классов, принимаются во внимание при вычислениях для конечных классов.
В некоторых руководствах говорится, что сумма всех кривых в реальном времени не может превышать 80% линейной скорости, другие говорят, что она не должна превышать 70% скорости линии. Какой из них правильный, или они оба ошибаются?
Они означают: вы не можете назначать приоритеты всему трафику ... Каждый раз, когда вы устанавливаете приоритет пакетов, приоритет других пакетов должен быть понижен. Если вы дадите чрезмерную гарантию, алгоритм станет бессмысленным. Определите класс, который получит приоритет, и определите классы, которые могут пострадать.
В одном руководстве говорилось, что вы забудете всю теорию. Независимо от того, как все работает на самом деле (планировщики и распределение полосы пропускания), представьте себе три кривые в соответствии со следующей «упрощенной моделью разума»: в реальном времени - это гарантированная пропускная способность, которую этот класс всегда будет получать. link-share - это пропускная способность, которую этот класс хочет полностью удовлетворить, но удовлетворение не может быть гарантировано. В случае избыточной пропускной способности классу может быть даже предложена пропускная способность больше, чем необходимо для удовлетворения требований, но он никогда не может использовать больше, чем указано в верхнем пределе. Чтобы все это работало, сумма всех полос пропускания в реальном времени не должна превышать xx% от скорости линии (см. Вопрос выше, процент варьируется). Вопрос: Это более-менее верно или полное непонимание HSFC?
Это верно.
И если вышеприведенное предположение действительно верно, то где в этой модели расстановка приоритетов? Например. каждый класс может иметь полосу пропускания в реальном времени (гарантированную), полосу пропускания общего доступа (не гарантированную) и, возможно, верхний предел, но все же некоторые классы имеют более высокий приоритет, чем другие классы. В этом случае я все равно должен каким-то образом расставить приоритеты, даже среди трафика в реальном времени этих классов. Могу ли я расставить приоритеты по наклону кривых? И если да, то какой кривой? Кривая в реальном времени? Кривая доли ссылки? Кривая верхнего предела? Все они? Могу ли я дать им всем одинаковый уклон или каждому свой, и как определить правильный уклон?
Разница между, например, HFSC и HTB - это то, что HFSC позволит вам точно определить, какой приоритет вы хотите иметь. Вы делаете это, определяя минимальную и максимальную границы с помощью значения dmax.
Наконец, руководство, которое, кажется, объясняет большинство несоответствий, а также то, чем текущая реализация отличается от исходной статьи:
http://manpages.ubuntu.com/manpages/precise/man7/tc-hfsc.7.html
Согласно этому руководству, многие другие руководства и сообщения на форумах о HFSC - полная чушь; это просто показывает, насколько сложен HFSC, поскольку многие люди, которые кажутся экспертами и делают вид, что полностью понимают HFSC, на самом деле имеют лишь частичное знание и делают ложные утверждения, основанные на непонимании концепции и того, как все эти настройки работают вместе.
Думаю, я наконец откажусь от HFSC. Если вы правильно настроите HFSC, это может быть лучшее качество обслуживания, которое вы можете получить, но шансы, что вы полностью испортите, намного выше, чем шансы на успех.
Если вы не можете связаться с оригинальными авторами, я бы попробовал следующее:
Также попробуйте проверить другие новые статьи, в которых упоминается эта. Возможно, появятся более новые статьи, которые являются продолжением исследований в этой области и могут включать дополнительную информацию по вопросам, которые вы задаете.
