Registrován: 13.05.2002
Příspěvků: 3362

Team Member: MOD

Tak v dalším release bude prostě ten řádek formulovaný

if(log_file) fclose(log_file);

Co by mě ale zajímalo dozvědět se od odvážných experimentátorů je jak dopadne třeba ta záměna MARK za CLASSIFY.. my už máme přeci jen příliš mnoho klientů na to, abych na nich chtěl dělat pokusy (zase ale můžu dobře optimalizovat pro hodně zatížené brány...).

__________________

Registrován: 11.09.2006
Příspěvků: 49

Ako si myslel zamenu MARK za CLASSIFY?

Registrován: 13.05.2004
Příspěvků: 777

proc bys nemoh delat experimenty ? Tady se delaji na brane site s 3400+ cleny ... a taky to jde

Registrován: 13.05.2002
Příspěvků: 3362

Team Member: MOD

No hlavní důvod asi je to měření objemu přenášených dat kvůli FUP... u nás se ten skript zavádí jednou denně a je problematické ho za běhu nějak restartovat. Možná by to CLASSIFY v Prometheovi mohli otestovat někde kde neuplatňují FUP a mají méně IPček a rychleji se jim ta pravidla načítají, takže se můžou snadno vrátit k předchozí verzi...

V zásadě na tom asi nebude mít co nefungovat... v iptables příkazu "CLASSIFY" místo "MARK", a "tc filter" řádka se vypustí úplně... (?)

__________________

Registrován: 04.12.2002
Příspěvků: 543

Tak jsem ti tam našel chybu. Při velké lince (75Mbit) ti přetýká proměnná v definici jedné z rootovských (myslím třetí úroveň) tříd. Vyjadřuju se asi pitomě, HTB zase tolik neznám a Cčko už vůbec ...

Asi by bylo potřeba ten tvůj kód trochu zauditovat, klasický typ INT už je asi trochu pasé. U nás se to projevilo tak, že místo 75Mbit jsme dostali na uploadu nějakých 17.

Tady je ta úprava, zahrň ji prosím do dalších releasů:

diff prometheus.c ./orig/prometheus.c
30d29
< #include "stdlib.h"
764,768c763
<
< //by ludvik
< sprintf(str,"%s -t mangle -F",iptables);
< safe_run(str);
<
---
>
985,986c980,981
< long rate=line;
< long max=line;
---
> int rate=line;
> int max=line;
1003c998
< tc, wan, parent, group->min, (long)(rate*up/line), (long)(max*up/line), burst);
---
> tc, wan, parent, group->min, (int)(rate*up/line), (int)(max*up/line), burst);

Registrován: 01.12.2002
Příspěvků: 352

Ti dám, já jsem se pachtil s hledáním, zatím co jsi čučel na hokej :-D

__________________

Registrován: 22.09.2005
Příspěvků: 43

kde najdem how to na prometheus? je vobec, alebo sa musim naucit z prikladov?

Registrován: 16.07.2002
Příspěvků: 166

__________________

Registrován: 04.12.2002
Příspěvků: 543

Zkus použít tu moji úpravu ... počítat se mi to dle tvých údajů nechce (konfigurák vypadá dobře, ještě může být chyba v definici hostů), ale třeba to také přeteče. U nás byl výsledek 17M upload ... A pokud máš v definici hostu "strop" výš, než je skutečně definovaná HTB třída, udělá to s pingama docela hokej. Prohlédni si také log od promethea.

Registrován: 13.05.2002
Příspěvků: 3362

Team Member: MOD

Jo, měl bych releasnout nějaký update, on tam byl skutečně nějaký problém s long vs. obyčejným integerem u toho uploadu a 16 Mbps.

__________________

Registrován: 16.07.2002
Příspěvků: 166

jo primlouvam se, myslel jsem ze to uz je opravene, i ta chybicka s volanim #include "stdlib.h",

nicmene, kolik by melo byt ve stroji pameti na bezproblemove fungovani 50M linky , zaroven to i natuje, cpu xeon 2x1,8 2Mcache. jeste dodavam FC6 jadro 2.6.20 x86_64
pripadne jak presne funguje ten tvuj script na natovani co je v make-snat-dnat ?

moc dekuji vsem co zatim pomohli

Naposledy upravil lukasw 30.05.2007 v 20:15

Registrován: 04.12.2002
Příspěvků: 543

paměť je dle mě naprosto fuk. zvlášť když gigo je okolo litru ...
2000 IP adres. ArchLinux, prometheus a SNAT : DNAT 1:1, obsazenost paměti 163M
Ale co mě teď zaráží je vytížení CPU C2D 2.1 - cca 40% každé jádro ... při nějakých 50-60 Mbitech (11k paketů) celkového průtoku. Ten SNAT bude muset asi pryč.

Registrován: 16.07.2002
Příspěvků: 166

no prave, mam tam gigo, a chci tam vrazit dalsi, a uvazuji ze tam dam 2 bloky po 2G misto 2x1, s vytizenim cpu nemam problem,
load average: 0.04, 0.02, 0.00 teda mozna ze o tom nevim

Registrován: 04.12.2002
Příspěvků: 543

zkus si prográmek htop. projeví se to v "kernelovém času", tj. červeně :-) V loadu se to nepozná, ten je nízký furt, pánbůh ví, co do toho všechno počítá.

Registrován: 16.07.2002
Příspěvků: 166

tak jsem z toho srna, pres rozhrani s prometheem nedostanu vice jak 20M,
vrazil jsem tam ten prometheus.c cos mi poslal opraveny, make prometheus bez chyby. jakmile ho shodim tak to fici, jakmile ho nahodim ,je to jako bych to nosil po disketach, zkusim tam jeste vrazit zpet tu 6ku a uvidim

na tu pamet jsem se ptal, protoze tam mam jenom 1G, ale ocividne to staci.

Registrován: 30.10.2002
Příspěvků: 733

Potrebuju se uplne zbavit limitu na objem dat, tedy tehle dvou veci

via-prometheus-magic-relative-limit 20 #*kb/sec->MB/day
via-prometheus-magic-relative-prio 20 #*kb/sec->MB/day

Prijde mi neeticke omezovat data timhle zpusobem a v czfree to nema co delat, kdo sosa, bude sosat pomalu.

Nedari se mi toho zbavit se. Porad to strasi v generovanych statistikach.

Ty statistiky nejsou zas tak nutne, stacilo by vzit prometheus.log, ten spustit pri startu igw a na binarku prometheus uplne zapomenout?

Diky
Zdenek

__________________