Верижна дисциплина SFQ

Quality of Service. Всичко свързано с трафик контрол.

Модератори: Freya, Kulu Ngile

Верижна дисциплина SFQ

Мнениеот Kulu Ngile » Вто 18, Дек, 2007 0:44

Stochastic Fairness Queuing – Стохастичното безпристрастно подреждане (SFQ) принадлежи към семейството на верижните дисциплини, основаващи се на „справедлив” алгоритъм на подреждане. Този алгоритъм е предложен от Джон Негъл през 1987г. Според подхода на Чък [11], тази дисциплина може да бъде обяснена по следния начин:
Безпристрастното подреждане (Fair queuing) е основата на един клас дисциплини за верижно класифициране, проектирани така, че да подсигурят на всеки клас равен достъп до мрежовите ресурси и да предотвратят завишаване консумацията от страна на засилен изходящ трафик. В FQ пакетите първо се класифицират от системата като потоци, а след това се отнасят към опашка, която специално е обвързана с този поток. След това опашките се обслужват пакет по пакет в циркулираща верига. Празните опашки се пропускат.
FQ се отнася и към поточните или поточно-базираните дисциплини

Изображение

FQ наподобява няколко врати. След като един пакет пристигне, той се класифицира и предава през една от вратите. Вратата е вход към опашка, която се обслужва заедно с няколко други опашки пакет по пакет в кръгообразен ред. По този начин обслужването на всяка опашка се осъществява „справедливо”.
Ключът към класифицирането на един поток е диалогичен, което означава цифрово представяне, основаващо се на tuple [изходен адрес, изходен порт, целеви адрес]. По-усъвършенстваните изпълнения могат да използват „комплекта” [изходен адрес, изходен порт, целеви адрес, протокол] за класифициране. Тъй като не е целесъобразно да се използва само една опашка за всеки диалог, SFQ е сборен хеширащ алгоритъм, който разделя трафика на ограничен брой опашки. Според Ларц [7]:
Stochastic Fairness Queueing (SFQ) е проста реализация на семейството на справедливите верижни алгоритми. Тя е сравнително по-неточна, но изисква по-малко изчисления, бидейки почти идеално безпристрастна. Ключова дума в SFQ е диалог (или поток), която отговаря предимно на една TCP-сесия или на UDP-поток. Трафикът се разделя на доста голям брой FIFO-опашки, по една за всеки диалог. След това трафикът се изпраща в циркулация, „давайки възможност на всяка сесия да изпрати информация”. „Това води до справедливо поведение и не позволява на един диалог да заглуши останалите.” SFQ се нарича Стохастична, тъй като тя реално не разпределя опашките за всяка сесия, а разполага с алгоритъм, който разделя трафика на ограничен брой опашки, използвайки друг, сборен алгоритъм. Заради сбора, множество сесии могат да се окажат в една и съща „кофа”, което би разполовило всяка сесия, по този начин разполовявайки и наличната ефективна скорост. За да се предотврати осезателното появяване на подобна ситуация, SFQ често сменя сборния си алгоритъм така, че сблъсъкът на всеки две сесии да отнеме само няколко секунди. Важно е да се знае, че „SFQ е полезна само, в случай че релния изходящ трафик действително е пълен!” Ако не е, на линукс машината няма да има опашка и тя няма да има ефект. Затова е добре тя да се комбинира с други qdisc.

Тук трябва да се споменат някои концепции: първо, SFQ разпределя доста голям брой FIFO-опашки; както бе казано, не е целесъобразно да се използва само една опашка за всяка връзка или диалог. Въпреки това, максималното увеличаване броя на опашките помага на доброто действие на алгоритъма.
Тъй като броя на опашките обикновено е по-малък от броя на потоците, сборния механизъм се използва за приобщаване на потоците, според комплектното им представяне в опашките. Приобщаването е стохастично и налага използването на дислокализиращ механизъм за реконфигуриране на сборния алгоритъм, стремящ се към подобряване на разпределянето. Параметрите са прости. Според Ларц [7]:
SFQ е по-скоро самонастройваща се:
- Perturb
Реконфигурирането на сборния алгоритъм се прави еднократно. Ако това не бъде извършено, той не може да бъде реконфигуриран отново, което не е препоръчително. „10 секунди е една добра стойност.”
- Quantum
Количеството байтове в потока, на които е позволено да бъдат освободени от опашката преди да дойде ред на следващата опашка. По подразбиране, 1 максимално оразмерен пакет (MTU-оразмерен). „Настройката не бива да бъде по-малка от MTU!”

Конфигуриране:
Код за потвърждение: Избери целия код
# tc qdisc add dev eth0 root sfq perturb 10

Статитиката може да бъде разгледана с команда 'tc show':
Код за потвърждение: Избери целия код
#tc -s -d qdisc show # -s = статистика; -d = детайли
.......................
qdisc sfq 800c: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb 10sec
Sent 4812 bytes 62 pkts (dropped 0, overlimits 0)


- 800c: това е автоматично назначен номер за манипулация.
- Limit означава, че в тази опашка може да има 128 пакета.
- Могат да бъдат изчислени 1024 hashbucket-а, като 128 от тях могат да бъдат активни по едно и също време (в опашката не могат да влязат повече пакети).
- Веднъж на всеки 10 секунди сборния алгоритъм се реконфигурира.

Тъй като борави с множество опашки и потоци едновременно, и е в състояние да ги приведе в някакъв ред, SFQ може да бъде разглеждана като „дружелюбна”. Разбира се, ако по подразбиране разполагаме с PHB, много потоци се изплъзват. Тук се намесва SFQ. Ако реконфигурираме PRIO, например, имаме AF11 потока в клас 1:1, AF21 потока в клас 1:2, а останалите потоци (PHB, по подразбиране) са в клас 1:3. Използваме qdisc TBF, за да контролираме производителността на класове 1:1 и 1:2, както и qdisc SFQ – в клас 1:3. Първо, диаграмата:

Изображение

А след това, конфигурационните команди:
Код за потвърждение: Избери целия код
# tc qdisc add dev eth0 root handle 1: prio
# tc filter add dev eth0 parent 1:0 prio 1 protocol ip u32 \
match ip tos 0x28 0xff flowid 1:1
# tc filter add dev eth0 parent 1:0 prio 2 protocol ip u32 \
match ip tos 0x48 0xff flowid 1:2
# tc filter add dev eth0 parent 1:0 prio 3 protocol ip u32 \
match ip 0/0 flowid 1:3
# tc qdisc add dev eth0 parent 1:1 handle 10: tbf rate 0.5mbit burst 5kb \
latency 70ms peakrate 1mbit minburst 1540
# tc qdisc add dev eth0 parent 1:2 handle 20: tbf rate 0.5mbit burst 5kb \
latency 70ms peakrate 1mbit minburst 1540
# tc qdisc add dev eth0 parent 1:3 handle 30: sfq perturb 10

Третата филтрираща команда гласи: всичко, което не съвпада, трябва да бъде пренасочено към клас 1:3, следващия с по-висок приоритет.

Източник: Основен
Ако съдбата е срещу теб, толкова по-зле за нея.

Изображение
APT HOWTO
Kulu Ngile
Унуфри
 
Мнения: 1233
Регистриран на: Съб 04, Мар, 2006 1:04
Местоположение: София

Назад към QoS

Кой е на линия

Потребители разглеждащи този форум: 0 регистрирани и 1 госта

cron