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

Чтение статей о 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 кбит / с, и если да, то какая разница?

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

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

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

Согласно имеющейся небольшой документации, кривая в реальном времени Конечным результатом всего этого является обеспечение того, чтобы первая пара пакетов VOIP отправлялась быстрее, чем что-либо еще, тем самым обеспечивая низкую задержку 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 мс - с абсолютной гарантией.

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

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

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

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

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