Re: [rlug] [ot] eepc
rzeno lt;[EMAIL PROTECTED]gt; wrote:gt; On Sat, Feb 16, 2008 at 09:15:17PM +0200, Abibula Aygun wrote:gt; gt; ghrt amp;lt;[EMAIL PROTECTED]amp;gt; wrote:amp;gt; Abibula Aygun wrote:amp;gt; amp;gt; ghrtgt; gt; wrote:amp;gt; amp;gt;amp;gt; Paul Lacatus wrote:amp;gt; amp;gt;amp;gt;amp;gt; Cit e de faptgt; gt; rezolutia ca nu prea e declarata?amp;gt; amp;gt;amp;gt;amp;gt;amp;gt; amp;gt;amp;gt; 800*480,gt; gt; 7amp;quot;amp;gt; amp;gt;amp;gt;amp;gt; amp;gt;amp;gt;amp;gt; amp;gt; Rezolutia maxima hackuita este degt; gt; 1024 * 600 :)amp;gt; amp;gt; Nu hackuita, ci scalata. Culmea e ca acum niste multigt; gt; ani am vazut un amp;gt; monitor Nokia care in 15amp;quot; scala si 1600*1200. Nugt; gt; arata prea grozav!SI hackuita si scalata 1024 * 600.Se folosesc de un servergt; gt; vnc , more details here :http://forum.eeeuser.com/viewtopic.php?id=14588gt; gt; _gt; gt; This mail sent using V-webmail - http://www.v-webmail.orggt; gt; ___gt; gt; fain, V-webmail asta, :)gt;nbsp;mie imi zici ? :DNu il sufar deloc dar ast ae alegere altora !nbsp; _ This mail sent using V-webmail - http://www.v-webmail.org ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
[rlug] ipset, iptables, performante
Salutare listasi. Stie careva unde as putea gasi o comparatie intre iptables cu n reguli si iptables + ipset (cu n reguli) la capitolul viteza ? Merita implementarea lui ipset pentru a elimina 1000 reguli din iptables (verificare IP + MAC) si implementarea acestora in ipset (macipmap) ? Peste tot am citit cum ca ipset ar face verificarile mai repede dar nicaieri n-am gasit un test comparativ. Ati implementat ipset undeva si ati vazut cresteri/scaderi de performante, etc? Merci ;) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] ipset, iptables, performante
Ca sa pun si eu o intrebare de baraj, dar e destul de heavy stuff, pentru ca tine de organizarea interna a memoriei la regulile de iptables. Se obtine ceva performanta in plus daca in loc sa fac o lista de 1000 de intrari in iptables fac cumva un hash pe una-doua-trei nivele astfel incat de fapt sa se evalueze sa zicem 10 + 10 + 10 reguli worst case in loc de 1000 worst case ? Teoretic la prima vedere ar trebui sa fie clar mai bine, dar spre exemplu daca cumva toate regulile din iptables sunt bagate spre exemplu intr-o lista si oricum dupa aia se evalueaza oricum toate la iteratie atunci canci, ca n-am facut nimic (de aia ziceam ca e heavy stuff). Cred ca cumva regulile sunt bagate intr-un copac ceva, sau un arbore de liste macar, dar necunoscand exact cum stau treburile, intreb si eu :-D Alex Andrei Kovacs wrote: Salutare listasi. Stie careva unde as putea gasi o comparatie intre iptables cu n reguli si iptables + ipset (cu n reguli) la capitolul viteza ? Merita implementarea lui ipset pentru a elimina 1000 reguli din iptables (verificare IP + MAC) si implementarea acestora in ipset (macipmap) ? Peste tot am citit cum ca ipset ar face verificarile mai repede dar nicaieri n-am gasit un test comparativ. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] ipset, iptables, performante
Andrei Kovacs wrote: Salutare listasi. Stie careva unde as putea gasi o comparatie intre iptables cu n reguli si iptables + ipset (cu n reguli) la capitolul viteza ? Merita implementarea lui ipset pentru a elimina 1000 reguli din iptables (verificare IP + MAC) si implementarea acestora in ipset (macipmap) ? Peste tot am citit cum ca ipset ar face verificarile mai repede dar nicaieri n-am gasit un test comparativ. ipset face un hashtable cu tabelele lui si cautarea va fi O(1) fata de a verifica rand cu rand un table de 1000 de intrari. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] ipset, iptables, performante
Alex 'CAVE' Cernat wrote: Ca sa pun si eu o intrebare de baraj, dar e destul de heavy stuff, pentru ca tine de organizarea interna a memoriei la regulile de iptables. Se obtine ceva performanta in plus daca in loc sa fac o lista de 1000 de intrari in iptables fac cumva un hash pe una-doua-trei nivele astfel incat de fapt sa se evalueze sa zicem 10 + 10 + 10 reguli worst case in loc de 1000 worst case ? Teoretic la prima vedere ar trebui sa fie clar mai bine, dar spre exemplu daca cumva toate regulile din iptables sunt bagate spre exemplu intr-o lista si oricum dupa aia se evalueaza oricum toate la iteratie atunci canci, ca n-am facut nimic (de aia ziceam ca e heavy stuff). Cred ca cumva regulile sunt bagate intr-un copac ceva, sau un arbore de liste macar, dar necunoscand exact cum stau treburile, intreb si eu :-D Alex Imi permit sa raspund. Se obtine performanta in plus in situatia descrisa de tine daca salturile in chain-uri nu depasesc timpul de parsare a celor 1000 de reguli initiale: - verificare /24, salt, verificare /25, salt, verificare /32 vs - verificare 1000 reguli. La un /22 in prima situatie ai maxim 4 reguli * maxim 2 * maxim 128 (in cazul in care regula este ultima din ultimul chain primar din ultimul chain secundar /25) = 1024. Din fericire, in practica, se vor parcurge in medie 512 pasi. Situatia, bineinteles, ar fi ajutata de un ESTABLISHED,RELATED ca prima regula in FORWARD (downside-urile le stim toti). Andrei Kovacs wrote: Salutare listasi. Stie careva unde as putea gasi o comparatie intre iptables cu n reguli si iptables + ipset (cu n reguli) la capitolul viteza ? Merita implementarea lui ipset pentru a elimina 1000 reguli din iptables (verificare IP + MAC) si implementarea acestora in ipset (macipmap) ? Peste tot am citit cum ca ipset ar face verificarile mai repede dar nicaieri n-am gasit un test comparativ. Merita. Aplicat la cateva /21-uri pe vlan-uri diferite diferenta in throughput a fost de 300-350 Mbps (in 1Gbps / out 1Gbps). Algoritmul de hashing este destul de ok cat sa iti rezolve problemele. (Experienta personala) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] ipset, iptables, performante
2008/2/17 Radu Oprisan [EMAIL PROTECTED]: Alex 'CAVE' Cernat wrote: Ca sa pun si eu o intrebare de baraj, dar e destul de heavy stuff, pentru ca tine de organizarea interna a memoriei la regulile de iptables. Se obtine ceva performanta in plus daca in loc sa fac o lista de 1000 de intrari in iptables fac cumva un hash pe una-doua-trei nivele astfel incat de fapt sa se evalueze sa zicem 10 + 10 + 10 reguli worst case in loc de 1000 worst case ? Teoretic la prima vedere ar trebui sa fie clar mai bine, dar spre exemplu daca cumva toate regulile din iptables sunt bagate spre exemplu intr-o lista si oricum dupa aia se evalueaza oricum toate la iteratie atunci canci, ca n-am facut nimic (de aia ziceam ca e heavy stuff). Cred ca cumva regulile sunt bagate intr-un copac ceva, sau un arbore de liste macar, dar necunoscand exact cum stau treburile, intreb si eu :-D Alex Imi permit sa raspund. Se obtine performanta in plus in situatia descrisa de tine daca salturile in chain-uri nu depasesc timpul de parsare a celor 1000 de reguli initiale: - verificare /24, salt, verificare /25, salt, verificare /32 vs - verificare 1000 reguli. E drept ca nu am chiar 1000 reguli una dupa alta ci am incercat impartirea pe subclase... adica 8 subclase de /25. Am incercat si varianta de /26 dar parerea mea e ca nu se mai obtin diferente majore la capitolul performanta (in loc de 8 reguli pentru clasificarea initiala a traficului se fac 16). In conditiile unei astfel de impartiri... mai imbunatateste ipset performantele (se reduc cele 8 reguli, ramane una). La un /22 in prima situatie ai maxim 4 reguli * maxim 2 * maxim 128 (in cazul in care regula este ultima din ultimul chain primar din ultimul chain secundar /25) = 1024. Din fericire, in practica, se vor parcurge in medie 512 pasi. Situatia, bineinteles, ar fi ajutata de un ESTABLISHED,RELATED ca prima regula in FORWARD (downside-urile le stim toti). Andrei Kovacs wrote: Salutare listasi. Stie careva unde as putea gasi o comparatie intre iptables cu n reguli si iptables + ipset (cu n reguli) la capitolul viteza ? Merita implementarea lui ipset pentru a elimina 1000 reguli din iptables (verificare IP + MAC) si implementarea acestora in ipset (macipmap) ? Peste tot am citit cum ca ipset ar face verificarile mai repede dar nicaieri n-am gasit un test comparativ. Merita. Aplicat la cateva /21-uri pe vlan-uri diferite diferenta in throughput a fost de 300-350 Mbps (in 1Gbps / out 1Gbps). Algoritmul de hashing este destul de ok cat sa iti rezolve problemele. (Experienta personala) Testele au fost cu macipmap (filtrare si dupa mac) ? Apropo... din cate mi se pare mie ipset nu ma lasa sa adaug mai multe MAC-uri pt un IP (tinand cont de hashing... e logic). Exista vreo solutie pentru asta (in afara de a elimina duplicatele :-) )? ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] ipset, iptables, performante
On Sunday 17 February 2008 23:19:32 Radu Oprisan wrote: Alex 'CAVE' Cernat wrote: Cred ca cumva regulile sunt bagate intr-un copac ceva, sau un arbore de liste macar, dar necunoscand exact cum stau treburile, intreb si eu :-D Alex Imi permit sa raspund. Se obtine performanta in plus in situatia descrisa de tine daca salturile in chain-uri nu depasesc timpul de parsare a celor 1000 de reguli initiale: - verificare /24, salt, verificare /25, salt, verificare /32 vs - verificare 1000 reguli. La un /22 in prima situatie ai maxim 4 reguli * maxim 2 * maxim 128 (in cazul in care regula este ultima din ultimul chain primar din ultimul chain secundar /25) = 1024. Din fericire, in practica, se vor parcurge in medie 512 pasi. Situatia, bineinteles, ar fi ajutata de un ESTABLISHED,RELATED ca prima regula in FORWARD (downside-urile le stim toti). Cred ca ai vrut sa zici de fapt 4 reguli + maxim 2 + maxim 128 adica 134 si nu 1024. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] ipset, iptables, performante
Octavian CHELU wrote: On Sunday 17 February 2008 23:19:32 Radu Oprisan wrote: Alex 'CAVE' Cernat wrote: Cred ca cumva regulile sunt bagate intr-un copac ceva, sau un arbore de liste macar, dar necunoscand exact cum stau treburile, intreb si eu :-D Alex Imi permit sa raspund. Se obtine performanta in plus in situatia descrisa de tine daca salturile in chain-uri nu depasesc timpul de parsare a celor 1000 de reguli initiale: - verificare /24, salt, verificare /25, salt, verificare /32 vs - verificare 1000 reguli. La un /22 in prima situatie ai maxim 4 reguli * maxim 2 * maxim 128 (in cazul in care regula este ultima din ultimul chain primar din ultimul chain secundar /25) = 1024. Din fericire, in practica, se vor parcurge in medie 512 pasi. Situatia, bineinteles, ar fi ajutata de un ESTABLISHED,RELATED ca prima regula in FORWARD (downside-urile le stim toti). Cred ca ai vrut sa zici de fapt 4 reguli + maxim 2 + maxim 128 adica 134 si nu 1024. I stand corrected. Nu stiu exact la ce m-am gandit, dar daca aflu va spun. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] ipset, iptables, performante
Andrei Kovacs wrote: 2008/2/17 Radu Oprisan [EMAIL PROTECTED]: Alex 'CAVE' Cernat wrote: Ca sa pun si eu o intrebare de baraj, dar e destul de heavy stuff, pentru ca tine de organizarea interna a memoriei la regulile de iptables. Se obtine ceva performanta in plus daca in loc sa fac o lista de 1000 de intrari in iptables fac cumva un hash pe una-doua-trei nivele astfel incat de fapt sa se evalueze sa zicem 10 + 10 + 10 reguli worst case in loc de 1000 worst case ? Teoretic la prima vedere ar trebui sa fie clar mai bine, dar spre exemplu daca cumva toate regulile din iptables sunt bagate spre exemplu intr-o lista si oricum dupa aia se evalueaza oricum toate la iteratie atunci canci, ca n-am facut nimic (de aia ziceam ca e heavy stuff). Cred ca cumva regulile sunt bagate intr-un copac ceva, sau un arbore de liste macar, dar necunoscand exact cum stau treburile, intreb si eu :-D Alex Imi permit sa raspund. Se obtine performanta in plus in situatia descrisa de tine daca salturile in chain-uri nu depasesc timpul de parsare a celor 1000 de reguli initiale: - verificare /24, salt, verificare /25, salt, verificare /32 vs - verificare 1000 reguli. E drept ca nu am chiar 1000 reguli una dupa alta ci am incercat impartirea pe subclase... adica 8 subclase de /25. Am incercat si varianta de /26 dar parerea mea e ca nu se mai obtin diferente majore la capitolul performanta (in loc de 8 reguli pentru clasificarea initiala a traficului se fac 16). In conditiile unei astfel de impartiri... mai imbunatateste ipset performantele (se reduc cele 8 reguli, ramane una). In situatia in care clasele sunt chiar un /22 (nu sunt pe sarite) nu te opreste nimic sa folosesti o singura regula de ipset si sa arunci totul acolo. La un /22 in prima situatie ai maxim 4 reguli * maxim 2 * maxim 128 (in cazul in care regula este ultima din ultimul chain primar din ultimul chain secundar /25) = 1024. Din fericire, in practica, se vor parcurge in medie 512 pasi. Situatia, bineinteles, ar fi ajutata de un ESTABLISHED,RELATED ca prima regula in FORWARD (downside-urile le stim toti). Andrei Kovacs wrote: Salutare listasi. Stie careva unde as putea gasi o comparatie intre iptables cu n reguli si iptables + ipset (cu n reguli) la capitolul viteza ? Merita implementarea lui ipset pentru a elimina 1000 reguli din iptables (verificare IP + MAC) si implementarea acestora in ipset (macipmap) ? Peste tot am citit cum ca ipset ar face verificarile mai repede dar nicaieri n-am gasit un test comparativ. Merita. Aplicat la cateva /21-uri pe vlan-uri diferite diferenta in throughput a fost de 300-350 Mbps (in 1Gbps / out 1Gbps). Algoritmul de hashing este destul de ok cat sa iti rezolve problemele. (Experienta personala) Testele au fost cu macipmap (filtrare si dupa mac) ? Apropo... din cate mi se pare mie ipset nu ma lasa sa adaug mai multe MAC-uri pt un IP (tinand cont de hashing... e logic). Exista vreo solutie pentru asta (in afara de a elimina duplicatele :-) )? Bineinteles ca exista. Elimini duplicatele :). ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
