Řešení 1:
Čtení článků o HFSC a jeho sestřenicích není dobrý způsob, jak tomu porozumět. Primárním cílem dokumentu HFSC je poskytnout přísný matematický důkaz svých tvrzení, nikoli vysvětlovat, jak to funguje. Skutečně nemůžete pochopit, jak to funguje ze samotného papíru HFSC, musíte si také přečíst dokumenty, na které odkazuje. Máte-li nějaký problém s tvrzením nebo jeho důkazy, pak může být dobrý nápad kontaktovat autory článků, jinak pochybuji, že by o vás měli zájem.
Napsal jsem tutoriál pro HFSC. Přečtěte si jej, pokud moje vysvětlení níže nejsou jasná.
K čemu vůbec potřebuji křivku v reálném čase? Za předpokladu, že A1, A2, B1, B2 jsou všechny 128 kbit/s sdílení spojení (žádná křivka v reálném čase pro žádný z nich), pak každý z nich dostane 128 kbit/s, pokud má kořenový adresář 512 kbit/s k distribuci (a A a B jsou oba 256 kbit/s samozřejmě), že? Proč bych dodatečně dával A1 a B1 křivku v reálném čase se 128 kbit/s? K čemu by to bylo dobré? Chcete-li dát těmto dvěma vyšší prioritu? Podle původního článku jim mohu dát vyšší prioritu pomocí křivky, o tom je koneckonců HFSC. Tím, že oběma třídám poskytnete křivku [256 kbit/s 20 ms 128 kbit/s], mají obě automaticky dvojnásobnou prioritu než A2 a B2 (stále dostanou pouze průměr 128 kbit/son)
Křivka v reálném čase a křivka sdílení odkazů se vyhodnocují různými způsoby. Křivka v reálném čase bere v úvahu, co třída dělala během celé své historie. Musí to udělat, aby poskytoval přesné přidělení šířky pásma a latence. Nevýhodou není to, co většina lidí intuitivně považuje za fér . Pokud si v reálném čase třída vypůjčí šířku pásma, když ji nikdo jiný nechce, bude penalizována, když ji někdo jiný později bude chtít zpět. To znamená, že v rámci záruky v reálném čase nemůže třída získat žádnou šířku pásma po dlouhou dobu, protože ji používala dříve, když ji nikdo nechtěl.
Sdílení odkazů je spravedlivé v tom, že nepenalizuje třídu za použití náhradní šířky pásma. To však znamená, že nemůže poskytnout silné záruky latence.
Oddělení sdílení odkazů od poskytování záruk latence je nová věc, kterou HFSC přináší, a článek to říká v úvodní větě:V tomto dokumentu studujeme hierarchické modely řízení zdrojů a algoritmy, které podporují oba propojení. sdílení a garantované služby v reálném čase s odděleným zpožděním (prioritou) a přidělením šířky pásma. Klíčové slovo v této větě je odděleno. V překladu to znamená, že se od vás očekává, že řeknete, jak má být nevyužitá šířka pásma sdílena s ls, a specifikujete, jaké záruky v reálném čase (také známé jako záruky latence) jsou potřeba s rt. Oba jsou ortogonální.
Započítává se šířka pásma v reálném čase do šířky pásma sdíleného propojením?
Ano. V dokumentu HFSC definují šířku pásma z hlediska toho, co třída odeslala od doby, kdy se třída stala nevyřízenou (tj. má pakety čekající na odeslání). Jediný rozdíl mezi rt a ls je, že rt se dívá dopředu pokaždé, když se třída zablokovala, a počítá nejnižší zaručenou šířku pásma z této sady, zatímco sdílení odkazů vypadá pouze od poslední doby, kdy se třída zablokovala. Takže rt bere v úvahu více bajtů než ls, ale každý bajt, který ls bere v úvahu, je také zohledněn rt.
Je horní limitní křivka aplikována také na real-time, pouze na link-share, nebo možná na obojí?
Horní limit nezabrání odesílání paketů, aby byly splněny podmínky v reálném čase. Pakety odeslané v podmínkách reálného času se stále započítávají do horního limitu, a proto mohou v budoucnu zpozdit odesílání paketů za podmínek sdílení odkazu. To je další rozdíl mezi sdílením v reálném čase a sdílením odkazů.
Za předpokladu, že A2 a B2 jsou oba 128 kbit/s, je nějaký rozdíl, jestli A1 a B1 jsou 128 kbit/s pouze sdílení spojení, nebo 64 kbit/s v reálném čase a 128 kbit/s sdílení spojení, a pokud ano, jaký rozdíl?
Ano, je to rozdíl. Jak je vysvětleno výše, pokud používáte reálný čas, jsou latence zaručeny, ale odkaz není sdílen spravedlivě (a zejména třída by mohla trpět nedostatkem šířky pásma) a horní limity nejsou vynucovány. Pokud používáte sdílení odkazu, latence není zaručena, ale sdílení odkazu je spravedlivé, nehrozí hladovění a je vynucena horní hranice. Před sdílením odkazu je vždy kontrolován reálný čas, nemusí to však znamenat, že sdílení odkazu bude ignorováno. Je to proto, že se pakety počítají jinak. Vzhledem k tomu, že historie je posuzována v reálném čase, nemusí být paket potřeba ke splnění záruky v reálném čase (kvůli jednomu započítanému z historie), ale je potřeba k uspokojení sdílení odkazu, protože ignoruje historický paket.
Pokud ke zvýšení priorit tříd použiji samostatnou křivku v reálném čase, proč bych vůbec potřeboval „křivky“? Proč není v reálném čase flatvalue a link-share také flat value? Proč jsou obě křivky? Potřeba křivek je z původního článku jasná, protože existuje pouze jeden atribut tohoto druhu na třídu. Ale teď, když mám tři atributy (v reálném čase, sdílení odkazů a horní limit), k čemu potřebuji křivky na každém z nich? Proč bych měl chtít, aby se tvar křivek (ne průměrná šířka pásma, ale jejich sklony) lišil pro provoz v reálném čase a sdílení odkazů?
Křivka pro ovládání v reálném čase vám umožňuje vyměnit úzkou latenci pro jednu konkrétní třídu provozu (např. VOIP) za špatnou latenci pro jiné třídy provozu (např. e-mail). Při rozhodování, který paket odeslat v rámci omezení v reálném čase, HFSC vybere ten, který dokončí odesílání jako první. K výpočtu však nepoužívá šířku pásma linky, ale šířku pásma přidělenou křivkou reálného času. Pokud tedy máme VOIP a e-mailové pakety stejné délky a VOIP paket má konvexní křivku, která poskytuje 10násobné zvýšení oproti konkávní křivce pro e-mail, pak bude 10 VOIP paketů odesláno před prvním e-mailovým paketem. Ale to se děje pouze po dobu shluku, což by mělo být maximálně doba potřebná k odeslání několika paketů – tj. milisekundy. Poté by se křivka VOIP měla vyrovnat a VOIP nezíská žádný budoucí nárůst, pokud na chvíli neustoupí (což by vzhledem k aplikaci VOIP s nízkou šířkou pásma mělo). Čistým výsledkem toho všeho je zajistit, že prvních pár VOIP paketů bude odesláno rychleji než cokoli jiného, čímž bude mít VOIP nízkou latenci na úkor toho, že e-mail bude mít vysokou latenci.
Jak jsem řekl dříve, protože sdílení odkazů nehledí na historii, nemůže poskytnout záruky latence. Pevná záruka je to, co je potřeba pro provoz v reálném čase, jako je VOIP. V průměru však konvexní křivka sdílená prostřednictvím odkazu bude stále poskytovat zvýšení latence provozu. Jen to není zaručené. To je v pořádku pro většinu věcí, jako je webový provoz přes e-mail.
Podle malého množství dostupné dokumentace jsou hodnoty křivek v reálném čase zcela ignorovány pro vnitřní třídy (třída A a B), aplikují se pouze na listové třídy (A1, A2, B1, B2). Pokud je to pravda, proč vzorová konfigurace ALTQ HFSC (hledejte 3.3 Sampleconfiguration) nastavuje křivky v reálném čase pro vnitřní třídy a tvrdí, že ty nastavují garantovanou míru těchto vnitřních tříd? Není to úplně zbytečné? (poznámka:pshare nastavuje křivku sdílení odkazu v ALTQ a mřížku křivky v reálném čase; můžete to vidět v odstavci nad ukázkovou konfigurací).
Dokumentace je správná. Hierarchie (a tedy vnitřní uzly) nemá žádný vliv na výpočet reálného času. Nemohu vám říct, proč si ALTQ evidentně myslí, že ano.
Některé návody říkají, že součet všech křivek v reálném čase nesmí být vyšší než 80 % rychlosti linky, jiné říkají, že nesmí být vyšší než 70 % rychlosti linky. Který z nich je správný, nebo se možná oba mýlí?
Obojí je špatně. Pokud má 70 % nebo 80 % vašeho provozu tvrdé požadavky na latenci, které musí být specifikovány v reálném čase, ve skutečnosti je téměř jistě nemůžete uspokojit odkazem, který používáte. Potřebujete rychlejší odkaz.
Jediný způsob, jak by si někdo mohl myslet, že by 80 % provozu mělo být v reálném čase, je, že by šlapal v reálném čase jako prioritu. Ano, za účelem poskytnutí záruk latence ve skutečnosti zvyšujete prioritu některých paketů. Mělo by to být ale jen na milisekundy. To je vše, s čím se může odkaz vyrovnat a stále poskytuje záruky latence.
Existuje velmi malý provoz, který vyžaduje záruky latence. VOIP je jedno, NTP druhé. Zbytek by měl být proveden sdílením odkazů. Pokud chcete, aby byl web rychlý, uděláte ho rychlým tím, že mu přidělíte většinu kapacity odkazů. Tento podíl je garantované dlouhodobě. Pokud chcete, aby měl nízkou latenci (v průměru), dejte mu konvexní křivku pod sdílením odkazů.
Jeden tutoriál řekl, že zapomenete na všechnu teorii. Bez ohledu na to, jak věci skutečně fungují (plánovače a distribuce šířky pásma), představte si tři křivky podle následujícího „modelu zjednodušené mysli“:reálný čas je zaručená šířka pásma, kterou tato třída vždy získá.link-share je šířka pásma, kterou chce tato třída být plně spokojeni, ale spokojenost nelze zaručit. V případě nadměrné šířky pásma může být třídě dokonce nabídnuta větší šířka pásma, než je potřeba k uspokojení, ale nikdy nemusí používat více, než říká horní limit. Aby to všechno fungovalo, součet všech šířek pásma v reálném čase nesmí být vyšší než xx % rychlosti linky (viz otázka výše, procento se liší). Otázka:Je toto více či méně přesné nebo úplné nepochopení HSFC?
Je to dobrý popis horní hranice. I když je popis sdílení odkazu přísně přesný, je zavádějící. I když je pravda, že sdílení odkazů neposkytuje tak tvrdé záruky latence jako v reálném čase, odvádí lepší práci při poskytování šířky pásma třídě než jeho konkurenti, jako jsou CBQ a HTB. Takže když říkáte, že sdílení odkazu "neposkytuje záruky", drží to na standardu vyšším, než může poskytnout jakýkoli jiný plánovač.
Popis v reálném čase dokáže být přesný, ale tak zavádějící, že bych to označil za špatné. Jak název napovídá, účelem reálného času není poskytovat garantovanou šířku pásma. Má poskytnout zaručenou latenci - tj. paket je odeslán HNED, ne o nějakou náhodnou dobu později v závislosti na tom, jak je odkaz použit. Většina provozu nepotřebuje zaručenou latenci.
To znamená, že ani reálný čas neposkytuje dokonalé záruky latence. Mohlo by to být, pokud by odkaz nebyl spravován také sdílením odkazu, ale většina uživatelů chce dodatečnou flexibilitu obou, a to není zadarmo. Reálný čas může zmeškat svůj termín latence v době, kdy je potřeba odeslat jeden paket MTU. (Pokud se to stane, bude to proto, že se vkradl MTU paketový odkaz, zatímco link v reálném čase zůstal nečinný pro případ, že by dostal paket s krátkou lhůtou, který musel být odeslán okamžitě. To je další rozdíl mezi sdílením odkazu a v reálném čase. Aby byly poskytnuty záruky, může reálný čas úmyslně ponechat linku v nečinnosti, i když jsou k dispozici pakety k odeslání, čímž je zajištěno méně než 100% využití spojení. Sdílení odkazů vždy využívá 100 % dostupné kapacity spojení. Na rozdíl od reálného času , dá se říci, že jde o „zachování práce“.)
Důvodem, proč lze říci, že reálný čas nabízí tvrdé záruky latence, je omezení zpoždění. Pokud se tedy pokoušíte nabídnout záruku 20 ms latence na 1Mbit/s linku a sdílení linky odesílá pakety o velikosti MTU (1500 bajtů), víte, že odeslání jednoho z těchto paketů bude trvat 12 ms. Pokud tedy v reálném čase řeknete, že chcete latenci 8 ms, stále můžete dodržet lhůtu 20 ms – s absolutní zárukou.
A pokud je výše uvedený předpoklad opravdu přesný, kde je v tomto modelu prioritizace? Např. každá třída může mít šířku pásma v reálném čase (zaručenou), sdílenou šířku pásma (není zaručena) a možná horní limit, ale přesto mají některé třídy potřeby vyšší priority než jiné třídy. V tom případě musím stále nějak upřednostňovat, dokonce i mezi provozem těchto tříd v reálném čase. Upřednostnil bych podle sklonu zatáček? A pokud ano, která křivka? Křivka v reálném čase? Křivka odkazu a podílu? Horní mez křivky? Všichni? Dal bych jim všem stejný sklon nebo každému jiný a jak zjistit správný sklon?
Neexistuje model stanovení priorit. Vážně. Pokud chcete dát provozu absolutní priority, použijte pfifo. K tomu slouží. Ale mějte také na paměti, že pokud dáte webovému provozu absolutní prioritu před e-mailovým provozem, znamená to, že necháte webový provoz nasytit odkaz, takže neprocházejí žádné e-mailové pakety, vůbec . Všechna vaše e-mailová spojení pak zemřou.
Ve skutečnosti nikdo nechce takové upřednostňování. To, co chtějí, je to, co poskytuje HFSC. Pokud skutečně máte provoz v reálném čase, HFSC to poskytuje. Ale bude to všechno. Pokud jde o zbytek, HFSC vám umožňuje říct „na přetíženém odkazu přidělte 90 % webu a nechte e-maily protékat 10 % a pošlete rychle ten lichý DNS paket, ale nenechte někoho, aby mě s ním DOS“.
Řešení 2:
Křivky můžete definovat pod různými názvy:
- rt, křivka v reálném čase, záruka šířky pásma/zpoždění.
- ls, křivka sdílení odkazů, sdílení šířky pásma/zpoždění (na základě konfigurace sousedních listů)
- ul, křivka horního limitu, maximální šířka pásma/zpoždění, kterého může dosáhnout.
K čemu vůbec potřebuji křivku v reálném čase? Za předpokladu, že A1, A2, B1, B2 jsou všechny 128 kbit/s sdílení spojení (žádná křivka v reálném čase pro žádný z nich), pak každý z nich dostane 128 kbit/s, pokud má kořenový adresář 512 kbit/s k distribuci (a A a B jsou oba 256 kbit/s samozřejmě), že? Proč bych dodatečně dával A1 a B1 křivku v reálném čase se 128 kbit/s? K čemu by to bylo dobré? Chcete-li dát těmto dvěma vyšší prioritu? Podle původního článku jim mohu dát vyšší prioritu pomocí křivky, o tom je koneckonců HFSC. Tím, že oběma třídám poskytnete křivku [256 kbit/s 20 ms 128 kbit/s], mají obě automaticky dvojnásobnou prioritu než A2 a B2 (stále dostanou pouze průměr 128 kbit/son)
Když vytvoříte definici v HFSC pouze s sazbami, automaticky se nastaví 'dmax' na 0. Což v podstatě znamená, že nebere v úvahu zpoždění. Dobrá konfigurace HFSC by měla zahrnovat hranice šířky pásma A zpoždění, které chcete pro svou třídu použít, jinak algoritmus nedokáže přesně zjistit, jakou prioritu by třída měla dostat.
Kdykoli dáte paketům prioritu, bude muset být priorita ostatních paketů snížena. Na základě hodnot 'dmax' a 'rate' budou všechny třídy multiplexovány pomocí virtuálních časovačů. Další informace naleznete v tc-hfsc(7).
Počítá se šířka pásma v reálném čase do šířky pásma sdíleného propojením? Např. pokud A1 a B1 mají pouze 64 kbit/s v reálném čase a 64 kbit/slink-share šířku pásma, znamená to, že jakmile jsou obsluhovány 64 kbit/s v reálném čase, jejich požadavek na sdílení spojení je také splněn (mohou získat nadměrnou šířku pásma, ale pojďme to na sekundu ignorovat) nebo to znamená, že získají dalších 64 kbit/s prostřednictvím sdílení odkazů? Má tedy každá třída „požadavek“ na šířku pásma v reálném čase plus sdílení odkazů? Nebo má třída vyšší požadavek než křivka v reálném čase, pouze pokud je křivka sdílení spojení vyšší než křivka v reálném čase (požadavek na sdílení aktuálního spojení se rovná specifikovanému požadavku na sdílení spojení mínus šířka pásma v reálném čase již poskytnutá této třídě)?
Pokud tok nepřekračuje hranice definice propojení a sdílení třídy, pak se křivka v reálném čase nikdy nepoužije. Definování křivky v reálném čase vám v tomto případě umožňuje např.:zaručit určitou 'dmax'.
Pokud jsou vaše definice sdílení odkazů bezchybné, pak byste křivky v reálném čase nepotřebovali. Mohli byste pouze definovat servisní křivky (sc), ale to by vaši konfiguraci ztížilo.
Je horní limitní křivka aplikována také na real-time, pouze na link-share, nebo možná na obojí? Některé návody říkají, že jeden způsob, někdo jiný. Někteří dokonce tvrdí, že horní limit je maximum pro šířku pásma v reálném čase + sdílenou šířku pásma? Jaká je pravda?
Křivka horního limitu vaší třídy se použije pouze na sdílení odkazu, když definujete křivku horního limitu, MUSÍTE definovat křivku sdílení odkazu. Stále se však používá horní křivka nadřazených tříd.
Za předpokladu, že A2 a B2 jsou oba 128 kbit/s, je nějaký rozdíl, jestli A1 a B1 jsou 128 kbit/s pouze sdílení spojení, nebo 64 kbit/s v reálném čase a 128 kbit/s sdílení spojení, a pokud ano, jaký rozdíl?
Je drobný rozdíl, pokud např. A2 =0 kbit/s a B2 =256 kbit/s. Pak bude virtuální čas pro A2 na maximu. Kdykoli jsou pakety klasifikovány v A2, budou okamžitě zpracovány. Křivka reálného času B2 však stále zajistí, že je schopen přenášet alespoň 64 kbit/s
Pokud ke zvýšení priorit tříd použiji samostatnou křivku v reálném čase, proč bych vůbec potřeboval „křivky“? Proč není v reálném čase flatvalue a link-share také flat value? Proč jsou obě křivky? Potřeba křivek je z původního článku jasná, protože existuje pouze jeden atribut tohoto druhu na třídu. Ale teď, když mám tři atributy (v reálném čase, sdílení odkazů a horní limit), k čemu potřebuji křivky na každém z nich? Proč bych měl chtít, aby se tvar křivek (ne průměrná šířka pásma, ale jejich sklony) lišil pro provoz v reálném čase a sdílení odkazů?
Křivky v reálném čase nesdílejí provoz mezi sousedními listy, ale křivky sdílení odkazů.
Podle malého množství dostupné dokumentace jsou hodnoty křivek v reálném čase zcela ignorovány pro vnitřní třídy (třída A a B), aplikují se pouze na listové třídy (A1, A2, B1, B2). Pokud je to pravda, proč vzorová konfigurace ALTQ HFSC (hledejte 3.3 Sampleconfiguration) nastavuje křivky v reálném čase pro vnitřní třídy a tvrdí, že ty nastavují garantovanou míru těchto vnitřních tříd? Není to úplně zbytečné? (poznámka:pshare nastavuje křivku sdílení odkazu v ALTQ a mřížku křivky v reálném čase; můžete to vidět v odstavci nad ukázkovou konfigurací).
Je pravda, že křivky v reálném čase jsou u vnitřních tříd ignorovány, aplikují se pouze na listové třídy. Nicméně křivky v reálném čase definované na těchto vnitřních třídách jsou brány v úvahu pro výpočty na listových třídách.
Některé návody říkají, že součet všech křivek v reálném čase nesmí být vyšší než 80 % rychlosti linky, jiné říkají, že nesmí být vyšší než 70 % rychlosti linky. Který z nich je správný, nebo se možná oba mýlí?
Znamená to, že nemůžete upřednostňovat veškerý provoz... Kdykoli dáte prioritu paketům, bude muset být priorita ostatních paketů snížena. Pokud budete ručit přehnaně, algoritmus ztrácí smysl. Definujte třídu, která získá prioritu, a definujte třídy, které mohou trpět.
Jeden tutoriál řekl, že zapomenete na všechnu teorii. Bez ohledu na to, jak věci skutečně fungují (plánovače a distribuce šířky pásma), představte si tři křivky podle následujícího „modelu zjednodušené mysli“:reálný čas je zaručená šířka pásma, kterou tato třída vždy získá.link-share je šířka pásma, kterou chce tato třída být plně spokojeni, ale spokojenost nelze zaručit. V případě nadměrné šířky pásma může být třídě dokonce nabídnuta větší šířka pásma, než je potřeba k uspokojení, ale nikdy nemusí používat více, než říká horní limit. Aby to všechno fungovalo, součet všech šířek pásma v reálném čase nesmí být vyšší než xx % rychlosti linky (viz otázka výše, procento se liší). Otázka:Je toto více či méně přesné nebo úplné nepochopení HSFC?
To je správně.
A pokud je výše uvedený předpoklad opravdu přesný, kde je v tomto modelu prioritizace? Např. každá třída může mít šířku pásma v reálném čase (zaručenou), sdílenou šířku pásma (není zaručena) a možná horní limit, ale přesto mají některé třídy potřeby vyšší priority než jiné třídy. V tom případě musím stále nějak upřednostňovat, dokonce i mezi provozem těchto tříd v reálném čase. Upřednostnil bych podle sklonu zatáček? A pokud ano, která křivka? Křivka v reálném čase? Křivka odkazu a podílu? Křivka horní hranice? Všichni? Dal bych jim všem stejný sklon nebo každému jiný a jak zjistit správný sklon?
Rozdíl mezi např. HFSC a HTB je, že HFSC vám umožní přesně definovat, jakou prioritu chcete, aby měl. To provedete definováním minimálních a maximálních hranic pomocí hodnoty 'dmax'.
Řešení 3:
Konečně průvodce, který, jak se zdá, vysvětluje většinu nesrovnalostí a také to, jak se současná implementace liší od původního článku:
http://manpages.ubuntu.com/manpages/precise/man7/tc-hfsc.7.html
Podle tohoto průvodce je mnoho dalších návodů a příspěvků na fóru o HFSC naprostý nesmysl; to jen ukazuje, jak komplikované HFSC je, protože mnoho lidí, kteří vypadají jako odborníci a předstírají, že plně rozumí HFSC, ve skutečnosti mají jen částečné znalosti a dělají nepravdivá tvrzení založená na nepochopení konceptu a toho, jak všechna tato nastavení spolu hrají.
Myslím, že se na HFSC konečně vykašlu. Pokud se vám podaří správně nastavit HFSC, může to být nejlepší QoS, jaké můžete získat, ale šance, že to úplně pokazíte, je mnohem vyšší než šance, že uspějete.