Deska na shapper

[reset]

podle me to lze delat jak pres TQ tak i SQ.

priklad SQ
- main SQ - 16Mb
-- sub SQ - 8Mb - user
-- sub SQ - 8Mb - user
-- ...........
-- sub SQ - 8Mb - user
-- sub SQ - 8Mb - user


pokud se naplni jeden user, tak ho to sejme, na 8Mb , pokud budou tahat tri uzivatele, tak je sejme nadrazena fronta, tak aby to neprelezlo 16Mb . Vse s pcq .
Lze to delal i pre TQ, ale prijde mi to jako extremne moc pravidel, takhle to lze vyresit celkem jednoduse.

Celkove reseni, ale trochu slozitejsi mam aplikovano nejak takto:

intranet --- SQ --- dmz --- TQ --- internet

Pred/Za touhle masinou s SQ mam jeste jednu, ktera tridi komunikaci podle priorit do TQ, tz. voice, games, zakladni komunikace, ostatni .
Jede na tom tahle 210 subnetu na 24Mb , priblizne 400pc, Kazdy user ma svuj subnet.

Vse bez problemu, celkove reseni bezi na dvou identickych masinach, na dualCore 2.5GHz , zarez kolem 5% (max do 10%) .
Bezi to uz takhle dobry rok, pripravuji drobnou optimalizaci.

Resit to lze vice zpusoby, zalezi na reseni. Vase samozrejme akceptuji a povazuji je taktez za spravne, protoze jsou vyzkouseny praxi

[mato1]

Pred/Za touhle masinou s SQ mam jeste jednu, ktera tridi komunikaci podle priorit do TQ, tz. voice, games, zakladni komunikace, ostatni .
Jede na tom tahle 210 subnetu na 24Mb , priblizne 400pc, Kazdy user ma svuj subnet.

Vse bez problemu, celkove reseni bezi na dvou identickych masinach, na dualCore 2.5GHz , zarez kolem 5% (max do 10%) .
Bezi to uz takhle dobry rok, pripravuji drobnou optimalizaci.

Resit to lze vice zpusoby, zalezi na reseni. Vase samozrejme akceptuji a povazuji je taktez za spravne, protoze jsou vyzkouseny praxi

mozem jedine potvrdit... dve masiny za sebou spravia velmi vela uzitocneho. ja mam teraz na jednej sieti ako hlavny shaper rb1000 a hned za nim je alix, ktory sluzi ako QoS, potom nasleduje managovatelny switch a ostatne routerborardy / alix ktore sluzia ako p2p spoje alebo sektory.

tecie tade 30 mbit, dokopy asi 350 ludi. rb1000 ide max na 50 percent (ale je tam komplikovany shaper, FW, FUP, ostatne skritpy...) a alix ide do 45-50 percent.
cele to ma minimalnu spotrebu a na obycajnom APC za 3000 Sk mi to vydrzi bez elektriny cely den
dana konfiguracia podla mna staci na 40-50 mbit a 500 ludi, potom uz nasleduje xeon server, ktory ma neuveritelny vykon, ale to ma zasa velku spotrebu

[Petr Vlašic]

Vetsinou to ted jede na serverech 1U RACK, chipova sada Intel 3000 a 4 jadro nejake lepsi s velkou cache (Xeon a kdyz nebyl k sehnani tak quad "obyc").

Mno a jak koukam, tak jsem rozviril diskuzi. Jen trosku dodam. Starej server byl AMD Sempron 2800+ a taky to stihal (i kdyz v te dobe tam bylo o kousek min pravidel cca 2900-3000) a CPU bylo 40-70%.

Jen par info o stroji. Ten s vetsim mnozstvim manglu:
uptime up 405 days
(Z TOPu) Cpu(s): 0.1%us, 0.0%sy, 0.0%ni, 95.9%id, 0.0%wa, 0.7%hi, 3.3%si, 0.0%st

Nevidim v tom problem a to vetsinou servery delaji dalsi potrebne veci pro sit - web, postu, DNS, NTP, ....

Z vlastních zkušeností můžu potvrdit, že i když je RoS pěkné nastavovací klikátko, tak po technické stránce je pořádný moloch a vůbec se takovému rozdílu nedivím(myslel jsem si, že to bude v SW i když ten Xeon v tom hraje také určitou roli. Zvláště pokud je jádro překompilováno přímo pro něj a ne pro generickou architekturu i586 jako v případě RoS. A o 64-bitu už se radši nebavím vůbec.). Jde totiž o to, že RoS od začátku drží všechny moduly(i těch sekcí, které se třeba vůbec nepoužívají, ovšem každý jeden paket přes ně musí) a nedá se moc optimalizovat. Na RB153 jsem stěží(vypnutý connection tracking a vůbec vše co vypnout šlo) dosáhl nějakých 40Mbps. Jen jsen nahodil OpenWRT, vyházel nepotřebné moduly a na routing jsem se hned dostal na 86Mbps a bridge jsem byl na plných 94Mbps! A to vůbec nemluvím o tom, že jsem do dnes na RoS nepřišel na to jak aktivovat opakovač integrovaný v řadě RB1XX(a kdo ví, třeba je i v jiných řadách a jen tak mimochodem to byl ten důvod proč mi to dávalo 0% zatížení CPU při 94Mbps jak už jsem tu někdy dříve psal).
BTW: Někteří BSDčkaři(NetBSD, FreeBSD,...) při slově Linux jen mávnou rukou. Nemá to někdo odzkoušené?

Ad zdejsi hlasky SQ ci QT. SQ nemusi pouzivat mangle, ale muze primo pouzivat "tc filter", kterym se da tez radit do queue. Ale dle me je to vykonove horsi a mene pouzitelne. Pripadne to muze mit routeros nejak extra upravene.

Není to nijak upravené ale je to jedno a to samé, protože je to v jádře ten samý netfilter a jestli se k jeho nastavování používá nějaká CLI aplikace nebo GUI klikátko už je jedno. Jen RoS některé věci řeší sám a trochu jinak(z.B. SQ).

[hapi]

neni náhodou MKčko kompilovaný pořád na i386? Taky by mohly kompilovat na i586, i686, amd64...

[Petr Vlašic]

neni náhodou MKčko kompilovaný pořád na i386?

Na strance Download jsou dva typy pro PC. Other X86 platform - generic i386 a Intel/AMD PC - i586.

Taky by mohly kompilovat na i586, i686, amd64...

A co teprv taková optimalizace pro jádra prescott, core2, amdfan10 aka barcelona,...

[hapi]

dva typy tam sice jsou ale stahujou to samí takže beztak i386

[Benny]

Zkousel jste nekdo tohle? http://www.alza.cz/gigabyte-m52l-s3-d87629.htm