Tak jako zárodek věcí příštích je v SVN nahraná nová feature "magic-fup-multiplier", která by se mohla hodit všem branám, které hledají "něco mezi" zpomalením na minimální zaručenou rychlost (ta s roustoucími požadavky na broadband a současně s rostoucí agregací začíná být čím dál více vzdálená nezaručenému maximu, aspoň u nás) a tarifem absoluteně bez FUP. Nám to dneska "zachránilo den", a i když doufám, že tuhle feature u tarifu bez FUP budu moci vypnout hned po dojednání upgradu, tak může být vhodná právě na taková krizová období, kdy správce brány vidí, že předchozí den neměl žádnou rezervu, a že takhle to dál nejde. (Samozřejmě záleží na přesném definování smluvního vztahu s klientem, jestli toto můžete aplikovat na tarify bez FUP .. my nikdy nikomu maximální rychlost negarantovali...). Název "magic-fup-multiplier" je možná matoucí, možná dříve než udělám release to přejmenuju třeba na "magic-rate-multiplier", že ano.. navrhněte, jak byste tomu říkali vy... už v tom začíná být zmatek ... a dokonce bych se přikláněl k tomu některé vysloveně nikým nepoužívané volby v konfiguráku úplně zrušit.
Další chystaná feature je "relativní" zpomalení - tedy ani zpomalení na garantované minimum, ani zpomalení na násobek tohoto minima, jako u předchozí feature - ale poměrné zpomalení (snížení HTB ceil) odvozené od nějakého násobku přenesených dat: dejme tomu kdo přenese 4 GB, tomu to zpomalí o 1 Mbps, kdo 8 GB, tomu o 2 Mbps atd - až do té doby, než se narází na min. rychlost (případně vynásobenou předchozím novým parametrem "fup-multiplier"). Řada operátorů to zjevně používá takhle, a asi je nesmyslné se tomu bránit.
No a nakonec obě předchozí feature plánuju zkombinat s tím "průběžným" zpomalování, tzn. ještě během aktuálního dne, což je asi jediný způsob, jak zabránit kolapsu sítě během večerní špičky.
Připomínám: první feature magic-fup-multiplier si už můžete checknout ze SVN, další dvě feature chystám, a popravě vypadá to, že budou nutně potřeba během zítřka.. jinak nás nesosající uživatelé sítě zlynčují (a ono je jich pořád výrazně víc, než těch sosajících, kterým se snad přeci jen ubráníme... pokud se nespojí s nějakou pátou kolonou uvnitř firmy...).
Hýbání s HTB ceilem v nějakém rozsahu je určitě dobrý nápad. Rozhodně lepší, než skokové zpomalení sosála na RATE. Už jsem si říkal, že si to tam dopíšu sám :-)
Prosímtě, až budeš dělat tu "okamžitou" aplikaci FUPky, mysli na to, že musíš mít někde bokem uložený konfigurák (a definici hostů), ze kterého to vzniklo (a tedy aplikovalo restartem promethea). On se totiž mezi dvěma restarty mohl stokrát změnit ...
Použil vůbec někdy někdo přepínače magic-fixed-limit a magic-fixed-prio ? (hodnoty se předpokládá, že jsou v MB, nebo v čem vlastně). Mě to kdysi napadlo, že to bude jedna věc se kterou budu experimentovat, ale nikdy jsem to nepoužil.. tak jsem si říkal, že bych to pro zvýšení přehlednosti vyhodil. Zatím to asi aspoň v ukázkových konfigurácích zakomentuju - asi stejně jako všechno, co mě nepžijde jako typicky používaná hodnota, nad kterou by někdo měl přemýšlet.
Přibude nám totiž asi 6 nových parametrů do konfiguráku, což mě přijde jako rostoucí zmatek. Nerad bych skončil jako squid (tedy aspoň po té stránce složitosti konfiguráku.. pokud "jen" bude konektivita tak levná a rychlá, že nikdo nebude potřebovat QoS, tak to by mě nevadilo.. ale to je stejně naivní představa, jako v 50. letech řeči o tom, že "jaderná energie umožní, že elektřina bude tak levná, že se přestane vyplácet její odebírání měřit".
ludvo, mám ale menší reklamaci na tvůj kód. myslím, že komentáře do /var/log/prometheus si začal psát až ty.. no a přijde mi, že to co je tam napsáno, je trochu blbost, konkrétně u root classy.
mno. taky asi jo, no :-) já vím že se tehdy musely ty parent třídy pro jednotlivé zaručené rychlosti dělat dost divně, aby se neutralizovalo to, že lidi s větší zaručenou rychlostí HTB rate dostávají větší podíl HTB ceil. Díky tomu skoro pořád sosali ti co měli větší rychlosti.. v podstatě to "bralo chudým a dávalo bohatým" :-) asi je to nějaký artefakt toho víceúrovňového členění, co jsem tam dal.
no, tak já jdu asi programovat to postupné zpomalování... akorát navíc potřebujeme, aby se nám to zpomalovalo pro stejná "klíčová slova" (keywords) v hosts různě, podle maximální rychlosti, a tentokrát ne podle minimální zaručené.. no prostě blázinec.
prohledej historii našich diskusí ohledně promethea. zvlášť moji část z doby přechodu na "classify". Tam bylo popsáno, jak se to má zkontrolovat. Výpis iptables neřekne vůbec nic. To určuje jenom do jaké rychlostní třídy ta IP spadne. A i kdyby nakrásně nefungovalo vůbec nic okolo HTB, tak statistiky budou vždy - ty se berou z iptables.
05.01.2009 v 09:53
