Я багато разів читав про Token Bucket фільтра в Linux (TBF) і до сих пір я не зовсім розумію , як я повинен обчислити burstі latencyпараметри, ганьба мені :(

Я припускаю, що розумна затримка становить близько 50 мс. Гаразд, але яке значення має лопнути?

На сторінці написано:

Останній розрахунок враховує розмір ковша, швидкість і, можливо, пірат (якщо встановлено). Ці два параметри взаємовиключні.

Отже, як пов’язана затримка з відром і фільтром? Чи існує формула для її обчислення? Або це просто питання: "Добре, X байт розриву і Y секунди затримки - це добре для мене"?

На сторінці сторінки єдине обмеження burstполягає в тому, що вона повинна бути достатньо високою, щоб дозволити налаштовану швидкість: вона повинна бути принаймні швидкістю / Гц. HZ - параметр конфігурації ядра; ви можете з’ясувати, що це у вашій системі, перевіривши налаштування ядра. Наприклад, на Debian ви можете:

$ egrep '^CONFIG_HZ_[0-9]+' /boot/config-`uname -r`
CONFIG_HZ_250=y

так що Гц у моїй системі становить 250. Для досягнення швидкості burstв 10 Мбіт / с мені знадобиться принаймні 10 000 000 біт / сек ÷ 250 Гц = 40 000 біт = 5000 байт. (Зверніть увагу, що більш високе значення в маніпуляції починається з тих пір, коли за замовчуванням було HZ = 100)

Але поза цим burstтакож є інструментом політики. Він налаштовує те, наскільки ви можете використовувати меншу пропускну здатність зараз, щоб "зберегти" її для подальшого використання. Однією загальною дією є те, що ви можете дозволити невеликим завантаженням (скажімо, веб-сторінки) проходити дуже швидко, одночасно зменшуючи великі завантаження. Ви робите це, збільшуючи burstрозмір, який ви вважаєте невеликим завантаженням. (Хоча ви часто переходите на класний qdisc типу htb, щоб ви могли сегментувати різні типи трафіку.)

Отже: ви налаштовуєте вибух як мінімум досить великий, щоб досягти бажаного rate. Крім того, ви можете додатково збільшувати його, залежно від того, що ви намагаєтеся досягти.

Концептуальна модель фільтра відра токена

«Відро» - це метафоричний об’єкт. Його ключові властивості полягають у тому, що він може вміщувати жетони, а також кількість обмежених жетонів обмежена - якщо ви намагаєтеся додати більше, він «переповнюється», а зайві жетони втрачаються (подібно до спроб покласти занадто багато води в фактичне відро). Розмір відра називається burst.

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

Існує (або може бути) рядок (черга) пакетів, які чекають жетонів. Це відбувається, коли відро порожнє або, можливо, має менше маркерів, ніж розмір пакета. На тротуарі перед відром є лише стільки місця, і кількість місця (у байтах) встановлюється безпосередньо limit. Крім того, його можна встановити опосередковано за допомогою latency(в ідеальному світі, обчислення було б rate× latency).

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

Останній шматок - це машина для виготовлення токенів, яка додає rate/ HZжетони до відра кожній галочці. (Ось чому ваше відро має бути принаймні таким великим, інакше деякі новоспечені жетони будуть негайно викинуті).

Ще одна відповідь на доповнення дероберта.

По-перше, посібник із сучасних процесорів Intel застарілий. Сучасні процесори мають таймери високої роздільної здатності, а сучасний Linux поставлений галочкою менше - буквально означає, що таймерів немає. Таким чином, всі ці коментарі, що роблять відра достатньо великими, щоб вмістити маркери в одному таймері, не мають значення. Насправді аналогія ковша була лише для того, щоб допомогти користувачеві зрозуміти взаємодію між деталізацією таймера та швидкістю передачі. Тепер, коли Linux має наносекундні таймери на сучасному апаратному забезпеченні, він втрачає свою корисність.

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

Наприклад, скажімо, що ваш параметр розриву tbf становить 10 К байт, а ваш показник швидкості tbf - 2 К байт / секунду, і ви наразі обмежені швидкістю (тобто вибух вичерпаний, тому ви обмежені відправленням у 2 кбіт / с). Якщо ви добровільно знизили швидкість, яку ви надсилаєте, до 1 Кбіт / с протягом 10 секунд, ви б знову накопичили ваші 10 К байтів надбавки (= (2000 [байт / сек] - 1000 [байт / сек]) * 10 сек). Утримування його нижче 1 кбіт / с більше 10 сек не матиме ефекту, оскільки tbf не дозволяє вам забороняти накопичувати більше, ніж параметр розриву .

Якщо ви перестали витрачати цілком, то ви отримаєте надбавку до вибуху знову через 5 сек (= 100000 [байт] / 2000 [байт / сек]).

Вам не доведеться повертати всі надбавки до вибуху, щоб використовувати його, ви можете використовувати стільки, скільки накопичили.

Ще один спосіб дивитися на це: вам дозволяється надсилати розрядні байти з необмеженою швидкістю, після чого ваша довгострокова середня швидкість ніколи не може перевищувати швидкість . Однак, оскільки це середньостроковий показник, якщо ви падаєте нижче ставки, вам дозволяється наздогнати, відправляючи на повній швидкості, - але навіть тоді вам дозволяється відправляти лише в повному обсязі, щонайбільше розривних байтів (а якщо це не так дозволити тебе наздогнати не можеш).

Інша зморшка - це TBF, має два з цих обмежувачів швидкості, і ваш трафік повинен проходити через обидва. У другому параметр розриву називається mtu і, а швидкість називається піктограмою . Ви повинні використовувати цю другу, щоб обмежити швидкість, на яку може надіслати перший, коли вона розривається. Використання цього другого є необов'язковим, і якщо ви не використовуєте його, то вивірки надсилаються зі швидкістю пристрою.

Нарешті, tbf має граничний параметр. Якщо програма наполегливо надсилає швидше, ніж швидкість , пакети будуть накопичуватися у черзі. Немає нескінченної пам’яті ядра, тому обмеження говорить, скільки байтів може накопичитися до того, як ядро ​​почне відкидати пакети.