Хтось насправді розуміє, як працює планування HFSC в Linux / BSD?

Я читав оригінальний документ SIGCOMM '97 PostScript про HFSC, це дуже технічно, але я розумію основну концепцію. Замість того, щоб давати лінійну криву обслуговування (як це стосується майже будь-якого іншого алгоритму планування), ви можете вказати опуклу або увігнуту службову криву, і таким чином можна розв'язати пропускну здатність і затримати. Однак, незважаючи на те, що в цьому документі згадуються певні алгоритми планування, що використовуються (в режимі реального часу та обміну посиланням), він завжди згадує лише ОДНУЮ криву на клас планування (розв'язка проводиться шляхом визначення цієї кривої, для цього потрібна лише одна крива ).

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

Ще гірше, що здається, що деяка версія ALTQ додає HSFC додатковий пріоритет черги (в оригінальному документі немає такого пріоритету). Я знайшов кілька BSD HowTo, які згадують цей параметр пріоритету (навіть незважаючи на те, що сторінка man в останньому випуску ALTQ не знає такого параметра для HSFC, тому офіційно його навіть не існує).

Все це робить планування HFSC ще складнішим, ніж алгоритм, описаний в оригінальному документі, і в Інтернеті є безліч навчальних посібників, які часто суперечать один одному, один з яких стверджує протилежне іншому. Це, мабуть, головна причина, чому, схоже, ніхто не розуміє, як насправді працює планування HFSC. Перш ніж я зможу задати свої запитання, нам потрібен зразок налаштування. Я буду використовувати дуже простий, як показано на зображенні нижче:

alt текст http://f.imagehost.org/0177/hfsc-test-setup.png

Ось кілька питань, на які я не можу відповісти, оскільки навчальні посібники суперечать один одному:

1. Для чого мені взагалі потрібна крива реального часу? Якщо припустимо, що A1, A2, B1, B2 - це всі 128-біт / с посилання (не крива в реальному часі для жодної), то кожен з них отримає 128 кбіт / с, якщо корінь має 512 кбіт / с для розподілу (і І A, і B - звичайно обидва 256 кбіт / с), правда? Чому б я додатково дав криві реального часу A1 і B1 зі швидкістю 128 кбіт / с? Для чого це було б добре? Щоб надати цим двом вищий пріоритет? Згідно з оригінальним документом, я можу надати їм більший пріоритет, використовуючи криву , ось що все-таки HFSC. Надаючи обом класам криву [256 кбіт / с 20 мс 128 кбіт / с], обидва мають вдвічі більше пріоритету, ніж A2 та B2 автоматично (все одно отримуючи лише 128 кбіт / с в середньому)

2. Чи враховується пропускна здатність у режимі реального часу до пропускної здатності спільного доступу? Наприклад, якщо A1 і B1 мають лише 64 кбіт / с в реальному часі і пропускну здатність обміну посиланням 64 кбіт / с, це означає, що коли вони обслуговуються 64 кбіт / с через реальний час, їхня вимога щодо частки зв'язку також буде задоволена (вони можуть отримати надлишкову пропускну здатність, але дозволяє ігнорувати це на секунду) чи це означає, що вони отримують ще 64 кбіт / с за допомогою link-share? Так чи має кожен клас "вимога" пропускної здатності в режимі реального часу плюс поділка посилання? Або клас має лише більш високу вимогу, ніж крива в режимі реального часу, якщо крива частки посилання вище кривої реального часу (поточна вимога долі посилання дорівнює вказаній вимозі частки посилання з мінусом пропускної здатності в реальному часі, вже наданої до цього клас)?

3. Чи застосовується також крива верхньої межі і в режимі реального часу, лише для обміну посиланнями, або, можливо, до обох? Деякі підручники говорять в один бік, в інші - в інший. Деякі навіть заявляють, що верхня межа є максимальним для пропускної здатності в режимі реального часу + пропускної здатності посилання-спільного використання? Що таке правда?

4. Якщо припустити, що A2 і B2 - це 128 кбіт / с, чи має це значення, якщо A1 і B1 - це лише 128 кбіт / с-поділ зв'язку, або 64 кбіт / с в режимі реального часу, і 128 кбіт / с, поділка зв'язку, і якщо так , яка різниця?

5. Якщо я використовую окрему криву в реальному часі для збільшення пріоритетів занять, навіщо мені взагалі потрібні «криві»? Чому в режимі реального часу не є рівне значення, а частка-посилання також є плоскою величиною? Чому обидві криві? Потреба в кривих ясна в оригінальному документі, оскільки в класі є лише один такий атрибут. Але тепер, маючи три атрибути (у режимі реального часу, обмін посиланнями та верхня межа), для чого мені ще потрібні криві на кожному? Чому я хотів би, щоб форма кривих (не середня пропускна здатність, а їх нахили) відрізнялася для реального часу та трафіку з використанням зв’язків?

6. Згідно з малою доступною документацією, значення кривих у режимі реального часу повністю ігноруються для внутрішніх класів (клас A і B), вони застосовуються лише для класів листів (A1, A2, B1, B2). Якщо це правда, чому конфігурація зразка ALTQ HFSC (пошук конфігурації 3,3 зразка ) встановлює криві реального часу для внутрішніх класів і стверджує, що вони встановлюють гарантовану швидкість цих внутрішніх класів? Хіба це не зовсім безглуздо? (зауважте: pshare встановлює криву частки зв'язку в ALTQ і натирає криву в режимі реального часу; це можна побачити в абзаці вище конфігурації зразка).

7. У деяких навчальних посібниках зазначається, що сума всіх кривих у режимі реального часу може бути не вище 80% швидкості лінії, інші кажуть, що вона не повинна бути вище 70% швидкості лінії. Який з них правильний чи вони, можливо, обидва помиляються?

8. В одному підручнику сказано, що ви забудете всю теорію. Незалежно від того, як реально працюють (планувальники та розподіл пропускної здатності), уявіть три криві відповідно до наступної "спрощеної моделі розуму": в режимі реального часу - це гарантована пропускна здатність, яку цей клас завжди отримуватиме. link-share - пропускна здатність, якою цей клас хоче повністю задовольнити, але задоволення не може бути гарантоване. Якщо є надлишкова пропускна здатність, клас може навіть запропонувати більше пропускної здатності, ніж потрібно для задоволення, але він ніколи не може використовувати більше, ніж говорить верхній межа. Щоб все це працювало, сума всіх смуг пропускання в режимі реального часу може бути не вище xx% від швидкості лінії (див. Питання вище, відсоток змінюється). Питання: Це більш-менш точне або повне непорозуміння HSFC?

9. І якщо припущення вище справді точно, то де пріоритет у цій моделі? Наприклад, кожен клас може мати пропускну здатність у режимі реального часу (гарантовано), пропускну здатність обміну посиланням (не гарантується) та, можливо, верхню межу, але все ж деякі класи мають більш високі пріоритетні потреби, ніж інші класи. У цьому випадку я все-таки повинен визначити пріоритет, навіть серед трафіку цих класів у режимі реального часу. Я б визначив пріоритет за нахилом кривих? І якщо так, то яка крива? Крива реального часу? Крива посилання-частка? Крива верхньої межі? Усі? Я б дав усім їм однаковий нахил або кожен інший і як дізнатися правильний схил?

Я досі не втрачав надії, що в цьому світі є хоча б рука, повна людей, які справді розуміли HFSC і здатні відповісти на всі ці питання точно. І зробити це, не суперечивши один одному у відповідях, було б дуже приємно ;-)

Читання статей про HFSC та його двоюрідних братів - це не гарний спосіб зрозуміти це. Основна мета статті HFSC - надати суворий математичний доказ своїх тверджень, не пояснюючи, як це працює. Дійсно, ви не можете зрозуміти, як це працює тільки з паперу HFSC, ви також повинні прочитати статті, на які він посилається. Якщо у вас є проблеми з претензією чи їхніми доказами, то, можливо, буде хорошою ідеєю звернутися до авторів робіт, інакше я сумніваюся, що вони зацікавлені почути від вас.

Я написав підручник для HFSC . Прочитайте, якщо мої пояснення нижче не зрозумілі.

Для чого мені взагалі потрібна крива реального часу? Якщо припустимо, що A1, A2, B1, B2 - це всі 128-біт / с посилання (не крива в реальному часі для жодної), то кожен з них отримає 128 кбіт / с, якщо корінь має 512 кбіт / с для розподілу (і І A, і B, звичайно, 256 кбіт / с), правда? Чому я б додатково давав криві реального часу A1 і B1 зі швидкістю 128 кбіт / с? Для чого це було б добре? Щоб надати цим двом вищий пріоритет? Згідно з оригінальним документом, я можу надати їм більший пріоритет, використовуючи криву, ось що все-таки HFSC. Надаючи обом класам криву [256 кбіт / с 20 мс 128 кбіт / с], обидва мають вдвічі більше пріоритету, ніж A2 та B2 автоматично (все одно отримуючи лише 128 кбіт / с в середньому)

Крива реального часу та крива обміну посиланнями оцінюються різними способами. Крива реального часу враховує те, що робив клас протягом усієї історії. Він повинен зробити це, щоб забезпечити точну пропускну здатність і розподіл затримки. Недоліком цього є не те, що більшість людей інтуїтивно вважають справедливим . У реальному часі, якщо клас запозичує пропускну здатність, коли ніхто інший цього не хоче, він штрафується, коли хтось ще хоче його пізніше. Це означає, що за гарантії реального часу клас не може отримати пропускну здатність протягом тривалого періоду, оскільки він використовував його раніше, коли ніхто не хотів.

Обмін посиланнями є справедливим, оскільки він не карає класу за використання запасної пропускної здатності. Однак це означає, що він не може дати гарантій затримки.

Відмежування спільного використання зв’язків від надання гарантій затримки - це нове, що HFSC приносить на стіл, і стаття так само говорить у своєму вступному реченні: У цій роботі ми вивчаємо ієрархічні моделі управління ресурсами та алгоритми, які підтримують як спільний доступ, так і гарантований. послуги в режимі реального часу з роз'єднаною затримкою (пріоритет) та розподілом пропускної здатності. Ключове слово в цьому реченні відокремлюється. У перекладі це означає, що від вас очікують сказати, яким чином невикористану пропускну здатність слід ділити з ls, і вкажіть, які гарантії в режимі реального часу (також гарантії затримки) потрібні для rt. Два є ортогональними.

Чи враховується пропускна здатність у режимі реального часу до пропускної здатності спільного доступу?

Так. У документі HFSC вони визначають пропускну здатність з точки зору того, що клас надіслав після того, як клас став відставанням (тобто, пакети, які очікують надсилання). Єдина відмінність між rt та ls - це rt з нетерпінням очікує кожного разу, коли клас відстає та обчислює найнижчу гарантовану пропускну здатність із цього набору, тоді як обмін посиланнями виглядає лише з останнього разу, коли клас відставав. Таким чином, rt враховує більше байтів, ніж ls, але кожен байт, який ls вважає, також вважається rt.

Чи застосовується також крива верхньої межі і в режимі реального часу, лише для обміну посиланнями, або, можливо, до обох?

Верхня межа не перешкоджає надсиланню пакетів для задоволення умови реального часу. Пакети, надіслані за умови реального часу, все ще зараховуються до верхньої межі, і, таким чином, цілком можуть затримати надсилання пакета під умовою обміну посиланням у майбутньому. Це ще одна різниця між реальним часом та часткою зв'язку.

Якщо припустити, що A2 і B2 - це 128 кбіт / с, чи має це значення, якщо A1 і B1 - це лише 128 кбіт / с-поділ зв'язку, або 64 кбіт / с в режимі реального часу, і 128 кбіт / с, поділка зв'язку, і якщо так , яка різниця?

Так, це має значення. Як було пояснено вище, якщо ви використовуєте в режимі реального часу, затримки гарантовані, але посилання розподіляється не справедливо (і, зокрема, клас може зазнати голодування пропускної здатності), і верхні межі не виконуються. Якщо ви використовуєте загальну частку посилань, затримка не гарантується, але обмін посиланням є справедливим, немає ризику голодування, і верхня межа застосовується. Реальний час завжди перевіряється перед поділом посилання, однак це не обов'язково означає, що частка посилань буде ігнорована. Це тому, що пакети рахуються по-різному. Оскільки історія розглядається в режимі реального часу, пакет може не знадобитися для забезпечення гарантії реального часу (через один підрахунок, включений в історію), але необхідний для задоволення частки посилання, оскільки він ігнорує історичний пакет.

Якщо я використовую окрему криву в реальному часі для збільшення пріоритетів занять, навіщо мені взагалі потрібні «криві»? Чому в режимі реального часу не є рівне значення, а частка-посилання також є плоскою величиною? Чому обидві криві? Потреба в кривих ясна в оригінальному документі, оскільки в класі є лише один такий атрибут. Але тепер, маючи три атрибути (у режимі реального часу, обмін посиланнями та верхня межа), для чого мені ще потрібні криві на кожному? Чому я хотів би, щоб форма кривих (не середня пропускна здатність, а їх нахили) відрізнялася для реального часу та трафіку з використанням зв’язків?

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

Як я вже говорив раніше, оскільки частка посилань не дивиться на історію, вона не може дати гарантій затримки. Постійна гарантія - це те, що потрібно для руху в режимі реального часу, наприклад VOIP. Однак, в середньому, крива, що поділяється опуклою кривою, все одно забезпечить затримку збільшення трафіку. Це просто не гарантується. Це добре для більшості речей, наприклад веб-трафіку електронною поштою.

Згідно з малою доступною документацією, значення кривих у режимі реального часу повністю ігноруються для внутрішніх класів (клас A і B), вони застосовуються лише для класів листів (A1, A2, B1, B2). Якщо це правда, чому конфігурація зразка ALTQ HFSC (пошук конфігурації 3,3 зразка) встановлює криві реального часу для внутрішніх класів і стверджує, що вони встановлюють гарантовану швидкість цих внутрішніх класів? Хіба це не зовсім безглуздо? (зверніть увагу: pshare встановлює криву частки посилання в ALTQ і натирає криву в режимі реального часу; це можна побачити в абзаці вище конфігурації зразка).

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

У деяких навчальних посібниках зазначається, що сума всіх кривих у режимі реального часу може бути не вище 80% швидкості лінії, інші кажуть, що вона не повинна бути вище 70% швидкості лінії. Який з них правильний чи вони, можливо, обидва помиляються?

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

Єдиний спосіб, коли хтось міг би подумати, що 80% трафіку має бути в режимі реального часу, це якби вони крокували в реальному часі як пріоритетний приріст. Так, для забезпечення гарантій затримки ви фактично збільшуєте пріоритетність деяких пакетів. Але це повинно бути лише на мілісекунди. Ось і все, з чим посилання може впоратися і все ще надавати гарантії затримки.

Трафіку дуже мало, що потребує гарантій затримки. VOIP - це одне, NTP - інше. Все інше слід виконати з обміну посиланнями. Якщо ви хочете, щоб веб був швидким, ви зробите його швидким, виділивши на нього більшу частину потужності посилань. Ця частка буде гарантована в протягом тривалого часу. Ви хочете, щоб вона була низькою затримкою (в середньому), надайте їй опуклу криву при спільному використанні посилань.

В одному підручнику сказано, що ви забудете всю теорію. Незалежно від того, як реально працюють (планувальники та розподіл пропускної здатності), уявіть три криві відповідно до наступної "спрощеної моделі розуму": в режимі реального часу - це гарантована пропускна здатність, яку цей клас завжди отримуватиме. link-share - пропускна здатність, якою цей клас хоче повністю задовольнити, але задоволення не може бути гарантоване. У випадку, якщо є надлишкова пропускна здатність, класу може бути запропоновано більше пропускної здатності, ніж потрібно для задоволення, але він ніколи не може використовувати більше, ніж говорить верхній межа. Щоб все це працювало, сума всіх смуг пропускання в режимі реального часу може бути не вище xx% від швидкості лінії (див. Питання вище, відсоток змінюється). Питання: Це більш-менш точне або повне непорозуміння HSFC?

Це хороша верхня межа опису. Хоча опис частки посилань суворо точний, він вводить в оману. Незважаючи на те, що справжня частка посилань не дає гарантій жорсткої затримки, як у реальному часі, вона робить кращу роботу, надаючи класу його пропускну здатність, ніж його конкуренти, як CBQ і HTB. Таким чином, кажучи, що частка посилань "не надає гарантій", вона утримує її на стандарт вище, ніж будь-який інший планувальник може надати.

Опис у реальному часі спроможний бути точним, але настільки оманливим, що я вважаю це неправильним. Як випливає з назви, мета реального часу - не гарантувати пропускну здатність. Він повинен забезпечити гарантовану затримку - тобто пакет надсилається ЗАРАЗ, а не якийсь випадковий проміжок часу пізніше, залежно від того, як використовується посилання. Більшість трафіку не потребує гарантованої затримки.

Однак, реальний час також не дає ідеальних гарантій затримки. Можливо, якщо посиланням не керуватиметься також поділка посилання, але більшість користувачів хочуть додаткової гнучкості обох, і це не приходить безкоштовно. У реальному часі може пропустити термін затримки до часу, необхідного для надсилання одного пакета MTU. (Якщо це трапиться, це станеться тому, що це було часткою пакету MTU пакетної посилання, в режимі реального часу зберігаючи посилання в режимі очікування, якщо йому було надано пакет із коротким терміном, який потрібно було відправити негайно. Це ще одна різниця між часткою посилання і в режимі реального часу. Для забезпечення своїх гарантій в режимі реального часу може навмисно тримати лінію в режимі очікування, навіть якщо є пакети для надсилання, при цьому забезпечується менше 100% використання посилань. Частка посилань завжди використовує 100% наявної ємності посилань. На відміну від реального часу ,

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

І якщо припущення вище справді точно, то де пріоритет у цій моделі? Наприклад, кожен клас може мати пропускну здатність у режимі реального часу (гарантовано), пропускну здатність обміну посиланням (не гарантується) та, можливо, верхню межу, але все ж деякі класи мають більш високі пріоритетні потреби, ніж інші класи. У цьому випадку я все-таки повинен визначити пріоритет, навіть серед трафіку цих класів у режимі реального часу. Я б визначив пріоритет за нахилом кривих? І якщо так, то яка крива? Крива реального часу? Крива посилання-частка? Крива верхньої межі? Усі? Я б дав усім їм однаковий нахил або кожен інший і як дізнатися правильний схил?

Не існує моделі пріоритетності. Серйозно. Якщо ви хочете надати абсолютний пріоритет трафіку, використовуйте pfifo. Саме це і є. Але також потрібно враховувати , що якщо ви даєте веб - трафік абсолютному пріоритет над поштовим трафіком, що означає дозволяючи веб - трафік наситити посилання і , таким чином , НЕ по електронній пошті пакетів не доходять, взагалі . Всі ваші електронні зв’язки потім відмирають.

Насправді ніхто не хоче такого пріоритетування. Те, що вони хочуть, - це те, що забезпечує HFSC. Якщо у вас фактично трафік у режимі реального часу, HFSC забезпечує це. Але це буде наповнювати все. Для решти, HFSC дозволяє вам сказати "на переповненому посиланні, виділіть 90% в Інтернеті і нехай електронна пошта прокручується разом на 10%, і о, швидко відправляйте непарний пакет DNS, але не дозволяйте комусь DOS мені з цим".

Ви можете визначити криві з різними назвами:

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

Для чого мені взагалі потрібна крива реального часу? Якщо припустимо, що A1, A2, B1, B2 - це всі 128-біт / с посилання (не крива в реальному часі для жодної), то кожен з них отримає 128 кбіт / с, якщо корінь має 512 кбіт / с для розподілу (і І A, і B, звичайно, 256 кбіт / с), правда? Чому я б додатково давав криві реального часу A1 і B1 зі швидкістю 128 кбіт / с? Для чого це було б добре? Щоб надати цим двом вищий пріоритет? Згідно з оригінальним документом, я можу надати їм більший пріоритет, використовуючи криву, ось що все-таки HFSC. Надаючи обом класам криву [256 кбіт / с 20 мс 128 кбіт / с], обидва мають вдвічі більше пріоритету, ніж A2 та B2 автоматично (все одно отримуючи лише 128 кбіт / с в середньому)

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

Щоразу, коли ви надаєте пріоритет пакетам, інші пакети повинні бути зменшені у пріоритеті. На основі значень "dmax" і "rate" всі класи будуть мультиплексовані за допомогою віртуальних таймерів. Для отримання додаткової інформації див. Tc-hfsc (7).

Чи враховується пропускна здатність у режимі реального часу до пропускної здатності спільного доступу? Наприклад, якщо A1 і B1 мають лише 64 кбіт / с в реальному часі і пропускну здатність обміну посиланням 64 кбіт / с, це означає, що коли вони обслуговуються 64 кбіт / с через реальний час, їхня вимога щодо частки зв'язку також буде задоволена (вони можуть отримати надлишкову пропускну здатність, але дозволяє ігнорувати це на секунду) чи це означає, що вони отримують ще 64 кбіт / с за допомогою link-share? Так чи має кожен клас "вимога" пропускної здатності в режимі реального часу плюс поділка посилання? Або клас має лише більш високу вимогу, ніж крива в режимі реального часу, якщо крива частки посилання вище кривої реального часу (поточна вимога долі посилання дорівнює вказаній вимозі частки посилання з мінусом пропускної здатності в реальному часі, вже наданої до цього клас)?

Якщо потік не йде за межі визначення класу link-share класу, то крива реального часу ніколи не використовується. Визначення кривої реального часу в цьому випадку дозволяє, наприклад: гарантувати певний dmax.

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

Чи застосовується також крива верхньої межі і в режимі реального часу, лише для обміну посиланнями, або, можливо, до обох? Деякі підручники говорять в один бік, в інші - в інший. Деякі навіть заявляють, що верхня межа є максимальним для пропускної здатності в режимі реального часу + пропускної здатності посилання-спільного використання? Що таке правда?

Крива верхньої межі вашого класу застосовується лише до спільного доступу, коли ви визначаєте криву верхньої межі, ОБОВ'ЯЗКОВО визначити криву частки зв'язку. Однак крива верхньої межі батьківських класів все ще застосовується.

Якщо припустити, що A2 і B2 - це 128 кбіт / с, чи має це значення, якщо A1 і B1 - це лише 128 кбіт / с-поділ зв'язку, або 64 кбіт / с в режимі реального часу, і 128 кбіт / с, поділка зв'язку, і якщо так , яка різниця?

Існує незначна різниця, якщо, наприклад, A2 = 0 кбіт / с і B2 = 256 кбіт / с. Тоді віртуальний час для A2 буде на максимумі. Кожного разу, коли пакети класифіковані в А2, вони будуть негайно оброблені. Однак крива 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, це може бути найкращий QoS, який ви можете отримати, але шанси на те, що ви повністю зіпсуєтеся, набагато вищі, ніж шанси на успіх.

Якщо ви не в змозі влаштуватися на оригінальних авторів, я б спробував це наступне:

1. увійдіть у дерево джерела ядра Linux і знайдіть файли C, які реалізують "рамку планування TC"
2. Подивіться на заголовок і знайдіть автора коду.
3. Програмісти електронної пошти "структури планування ТС" просять у них літератури про їх реалізацію.

Спробуйте також перевірити інші нові документи, які цитують цю. Там можуть бути новіші статті, які є продовженням досліджень у цій галузі та можуть містити більше інформації про запитання, які ви задаєте.