Tohle je jako vystrizeny ze zpravy, kterou UPC zduvodnilo zavedeni FUP, neboli datovych limitu. Mam jiny navrh reseni, ktere vymyslel myslim Make: Cim vice uzivatel stahne, tim pomaleji mu to pobezi. Takze prvnich rekneme 10MB pojede relativne rychle, ale dalsi treba hodinu to pojede pomalu. Proste nejakej program, kterej bude sledovat jak moc sit kdo vytezuje a podle toho regulovat rychlosti, samozrejmne tak, aby to nejlepe jelo tem, kdo browsi po inetu a stahuju male objemy a nejpomaleji aby to jelo vecnym sosalum. Ma to jen jeden hacek: napsat ten program )
Ano, ale u nás je to udělané v podstatě úplně stejně - omezení na minimální garantovanou rychlost proběhne až při výrazném překročení FUP během 24hodin. Kromě toho se htb ceil odebírá sice automaticky, ale (podle aktuální situace) někdy celý všem kdo FUP překročí, a někdy postupně - kdo překročí nejvíc, je na garantovaném minimu, kdo překročí mín, má přeci jen nějaký HTB ceil, apod. S tímhle experimentuju.
Jinak FUP je až poslední řešení... jenže problém je, že není ucpaná iGW (ta má rezervu), ale Wi-Fi - ale i na páteří je problém, že rozdíl mezi htb rate a ceil je u nás někdy docela vysoký, a že nevidím důvod, proč by ti kteří stahují málo neměli mít lepší ceil než ti, kteří stahují hodně. Ted taky uvažuju, že se bude HTB priorita dynamicky měnit podle množství přenesených dat - člověk, který stáhne třeba polovinu objemu FUP, sice nepříjde o svůj HTB ceil, ale dostane ho s nižší prioritou. Tohle všechno bude řešit nový release Prometheus QoS v 0.5 (aneb dejme zbraně hromadného ničení do rukou masám :-)
To, že prvních 10 MB se stahuje rychleji než 1 GB, to nějak řeší HTB samo o sobě - jenže má s těmi svými tokeny nějaký problém když už všichni sosají celý den - ty countery se prostě nějak přetočí a všichni jsou zase na startu kredit je smazaný.
Nicméně - v mém Prometheus QoS už dnes jde udělat to, že se třeba bude spouštět ne jednou denně, ale jednou za hodinu, a tím se dosáhne téměř přesně toho, o čem mluvíš - bude to vlastně hodinová FUP. Udělat to ne na základě času ale na základě přenesených dat (prvních 10 MB za den rychle, pak zpomalení - no jo, jenže to je vlastně ještě brutálnější omezení než moje 48h FUP :-) by s určitou modifikací šlo taky - nebráním se tomu, pokud mi tu programátorskou práci někdo zaplatí (je to pár hodin práce) a nebude mu vadit, že to pak releasnu jako open source.
a nesla by ta propustnost definovat jako procentuelne?
uvedu priklad..
mame napr. 100Mbit full duplex spoj a ..
- 50% bude vyuzito pro inet (50Mbit..)
- 50% bude vyuzito pro CZF (50Mbit..)
a u CZF tafiku definovat to, ze kazdy kdo se do te site "prihlasi" (zapne comp) tak to pro nej vyhradni procentuelni pasmo pro sosani v CZF..
V siti bude zapnuto deset pc, kdy kazde PC (IP) dostane vyhrazene pasmo 10% (100% = 50Mbit.. pro CZF) a ikdyz nebudou vsichni sosat z CZF bude proste tato sire pasma pro ne pripravena.
Pochopitelne by se pri vetsim poctu PC (IP) pocet delil procetuelne pro vsechny v teto siti stejne, aby to bylo demokraticke vyuziti pasma.
Tento system by pochopitelne neplatil pro trafik z netu, protoze si kazdy plati jinou rychlost. (zalezi na mistnich podminkach)
U nás máme paušální pladbu za inet a zas následující model :
1.SSH, hry a podobné interaktivní služby mají nejvyšší prioritu a garantováno maximálně 10% linky
2. http, FTP a podobně má stření prioritu a roztahuje se na úkor P2P provozu.
3. P2P má garantováno minimálně 25% linky a pak to co zbyde.
V každém pásmu dostává každá IP jednu ntinu pásma podle aktuálního provozu.
V praxi to na 3 Mb lince jedoucí na 100% znamelo stále malé pingy ve hrách a rozumnou rychlost http a podobných. Nyní máme 20 Mb linku jedoucí v průměru na 30%, tak tam není vůbec co řešit. Nicmémě při našem Qosu může sosal sosat jak chce, může s ostatními sosaly zabrat
třeba i 90% linky a nemá to na normální lidi žádný vliv.
Kolik procent uživatelů čerpá kolik procent prostředků sítě...
07.03.2005 v 09:01
)
