Wiele razy czytałem o filtrze kubełkowym Linuksa (TBF) i wciąż nie rozumiem, jak powinienem obliczyć parametry bursti latency, wstydź się :(

Przypuszczam, że rozsądne opóźnienie wynosi około 50 ms. OK, ale jaką wartość powinna przyjąć seria?

Strona zawiera:

Te ostatnie obliczenia uwzględniają rozmiar segmentu, szybkość i być może szczytową wartość (jeśli jest ustawiona). Te dwa parametry wzajemnie się wykluczają.

W jaki sposób opóźnienie jest związane z segmentem i filtrem? Czy istnieje wzór na jego obliczenie? Czy jest to po prostu kwestia: „OK, X bajtów serii i Y sekund opóźnienia są dla mnie dobre”?

Na stronie podręcznika jedynym ograniczeniem burstjest to, że musi być wystarczająco wysoka, aby umożliwić skonfigurowaną szybkość: musi to być co najmniej szybkość / HZ. HZ jest parametrem konfiguracyjnym jądra; możesz dowiedzieć się, co to jest w twoim systemie, sprawdzając konfigurację jądra. Np. W Debianie możesz:

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

więc HZ w moim systemie wynosi 250. Aby uzyskać szybkość 10 Mb burst/ s, potrzebowałbym co najmniej 10 000 000 bitów / s ÷ 250 Hz = 40 000 bitów = 5000 bajtów. (Uwaga: wyższa wartość na stronie podręcznika pochodzi z sytuacji, gdy HZ = 100 było wartością domyślną).

Ale poza tym burstjest także narzędziem polityki. Konfiguruje zakres, w jakim można teraz użyć mniejszej przepustowości, aby „zapisać” ją na przyszłość. Jedną z powszechnych rzeczy jest to, że możesz chcieć pozwolić, aby małe pliki do pobrania (powiedzmy strona internetowa) działały bardzo szybko, a jednocześnie dławiły duże pliki do pobrania. Robisz to, zwiększając burstrozmiar do rozmiaru, który uważasz za małe pobranie. (Często jednak przełączasz się na klasyczną qdisc, taką jak htb, dzięki czemu możesz segmentować różne typy ruchu).

Zatem: konfigurujesz, aby seria była co najmniej wystarczająco duża, aby osiągnąć pożądane rate. Poza tym możesz go zwiększyć, w zależności od tego, co próbujesz osiągnąć.

Model koncepcyjny filtra kubełkowego żetonów

„Wiadro” to obiekt metaforyczny. Jego kluczowymi właściwościami jest to, że może przechowywać tokeny, a liczba tokenów, które może przechowywać, jest ograniczona - jeśli spróbujesz dodać więcej, „przepełnia się”, a dodatkowe tokeny są tracone (tak jak próba włożenia zbyt dużej ilości wody do rzeczywiste wiadro). Rozmiar wiadra nazywa się burst.

Aby faktycznie przesłać pakiet do sieci, pakiet ten musi uzyskać tokeny równe jego rozmiarowi w bajtach lub mpu(w zależności od tego, który jest większy).

Istnieje (lub może być) linia (kolejka) pakietów oczekujących na tokeny. Dzieje się tak, gdy wiadro jest puste lub alternatywnie ma mniej tokenów niż rozmiar pakietu. Na chodniku przed wiadrem jest tylko tyle miejsca, a ilość miejsca (w bajtach) jest ustawiana bezpośrednio przez limit. Alternatywnie można go ustawić pośrednio za pomocą latency(w idealnym świecie obliczenia będą wynosić rate× latency).

Kiedy jądro chce wysłać pakiet z filtrowanego interfejsu, próbuje umieścić pakiet na końcu linii. Jeśli na chodniku nie ma miejsca, jest to niefortunne dla pakietu, ponieważ na końcu chodnika jest dół bez dna, a jądro upuszcza pakiet.

Ostatnim elementem jest maszyna do robienia żetonów, która dodaje rate/ HZżetony do wiadra za każdym razem. (Właśnie dlatego twoje wiadro musi być co najmniej tak duże, w przeciwnym razie niektóre z nowo wybitych żetonów zostaną natychmiast odrzucone).

Kolejna odpowiedź na uzupełnienie deroberta.

Po pierwsze, w nowoczesnych procesorach Intela instrukcja jest nieaktualna. Nowoczesne procesory mają timery o wysokiej rozdzielczości, a współczesny Linux ma mniej tykania - dosłownie oznacza to, że nie ma tykania timera. Dlatego wszystkie te komentarze, które powodują, że wiadra są wystarczająco duże, aby pomieścić tokeny w jednym zegarze, są bez znaczenia. W rzeczywistości analogia segmentu była tylko po to, aby pomóc użytkownikowi zrozumieć interakcję między ziarnistością timera a prędkością wysyłania. Teraz, gdy Linux ma liczniki nanosekundowe na nowoczesnym sprzęcie, traci swoją przydatność.

W przypadku TBF parametrem serii jest liczba bajtów, które można wysłać z nieograniczoną prędkością, zanim zacznie działać ograniczenie prędkości (określone przez szybkość ). Po uruchomieniu ograniczenia prędkości jedynym sposobem na ponowne rozerwanie jest ograniczenie wysyłania poniżej tej prędkości .

Na przykład, powiedzmy, że twój parametr serii tbf wynosi 10 kB, a parametr szybkości tbf wynosi 2 kB / sekundę, a obecnie masz ograniczoną szybkość (tj. Seria jest wyczerpana, więc jesteś ograniczony do wysyłania z prędkością 2 kb / s). Jeśli dobrowolnie zmniejszysz szybkość wysyłania do 1 Kb / s przez 10 sekund, ponownie akumulujesz swój limit 10 000 bajtów na sekundę (= (2000 [bajtów / sek] - 1000 [bajtów / sek]) * 10 sek.). Utrzymywanie go poniżej 1 kb / s przez ponad 10 sekund nie przyniosłoby żadnego efektu, ponieważ tbf nie pozwala na gromadzenie więcej niż parametru serii .

Jeśli przestaniesz całkowicie wydawać pieniądze, w ciągu 5 sekund odzyskasz swój limit serii (= 100000 [bajtów] / 2000 [bajtów / sek]).

Nie musisz odzyskać całego limitu wybuchu, aby go użyć, możesz wykorzystać tyle, ile zgromadziłeś.

Innym sposobem spojrzenia na to jest: możesz wysyłać bajty serii z nieograniczoną prędkością, po czym Twoja długoterminowa średnia prędkość nigdy nie przekroczy prędkości . Ponieważ jednak jest to średnia długoterminowa, jeśli spadniesz poniżej stawki, możesz nadrobić zaległości, wysyłając z pełną prędkością - ale nawet wtedy możesz wysyłać z pełną prędkością dla co najwyżej serii bajtów (a jeśli to nie jest pozwalają ci nadrobić zaległości, których nie możesz).

Drugim zmarszczeniem jest to, że TBF ma dwa z tych ograniczników prędkości, a twój ruch musi przejść przez oba. W drugim parametrze serii nazywa się mtu i, a szybkość nazywa się wartością szczytową . Powinieneś użyć tego drugiego, aby ograniczyć prędkość, z jaką pierwszy może wysyłać swoje serie. Korzystanie z tego drugiego jest opcjonalne, a jeśli go nie użyjesz, wysyłane są z prędkością urządzenia.

Wreszcie tbf ma parametr limitu . Jeśli program stale wysyła szybciej niż szybkość , pakiety będą się gromadzić w kolejce. Nie ma nieskończonej pamięci jądra, więc limit określa, ile bajtów może się zgromadzić, zanim jądro zacznie odrzucać pakiety.