[GTER] RES: Quagga

Antonio Carlos Pina antoniocarlospina at gmail.com
Wed Apr 1 13:41:08 -03 2009


40kpps é MUUUUITO pouco.

Abs

2009/4/1 Alfredo Dal´Ava Júnior <alfredo.dalava at gmail.com>

> Desculpem a ignorância, mas tenho observado este assunto à algum tempo,
> desde a reunião GTER26 em São Paulo.
>
> Como é que vocês medem esta performance? Quero dizer... medir pacotes por
> segundo está Ok, mas como vocês medem este gargalo? Drops na interface de
> rede?
>
> Pergunto pelo seguinte.. tenho como exemplo uma maquina simples, com picos
> de 40Kpps, 4 placas de rede xing ling (leia-se Realtek e Hangzhou Silan
> Microelectronics) e 1 placa Via Rhine III (onboard) e não consigo botar
> defeito pra provar por A+B que se precisa investir em placas Intel/3Com,
> etc.
> Se elas representam um gargalo eu não sei, porque não tenho como comprovar
> e
> não tenho outra base semelhante pra comparar.
>
> Não tem error, drop, overruns, collisions nas interfaces. CPU 94% idle e
> load average 0.21 0.16 0.10. Tem 1061 regras de iptables, divididas entre
> firewall, NAT, NAT/Redirect em kernel Linux 2.6.25.
>
> Será que 40kpps é muito pouco trafego pra apresentar algum problema e essa
> situação é realmente aceitavel?
>
> []'s
> Alfredo
> 2009/4/1 Antonio Carlos Pina <antoniocarlospina at gmail.com>
>
> > A performance em FreeBSD é muito superior, até o momento que se coloca a
> > primeira linha de firewall. Aí ela cai para 1/3. Por exemplo, consegue-se
> > 700Kpps fácil, vai para 350 com erros no primeiro ipfw any any (mesmos
> > resultados com ipfilter)
> >
> > No Linux vai-se até 350, 400kpps, mas você consegue o mesmo com iptables
> > (sempre usando polling, claro)
> >
> > Os melhores resultados são conseguidos com a família 4.x, sendo 4.08 o
> > melhor de todos.
> >
> > O penalty do salvamento do contexto no nível de interrupção e código é
> > muito
> > maior trocando de core para core (quase 4 vezes a quantidade de linhas de
> > código).
> >
> > Abs
> >
> > 2009/4/1 Luiz Otavio O Souza <luiz at visualconnect.com.br>
> >
> > >
> > >> Entretanto, Juliano, Quando você distribui as interrupções, o processo
> > de
> > >> salvar o contexto impacta imensamente na performance, fora detalhes
> como
> > >> cache de código.
> > >>
> > >> Travando o affinity a performance é muito superior.
> > >>
> > >
> > > Pina,
> > >
> > > Os context switchs vão acontecer com e sem affinity de CPU... Para você
> > ter
> > > uma idéia no FreeBSD você tem no mínimo 2000 context switcs por segundo
> > (com
> > > HZ=1000) fora aqueles que são gerados para atender as interrupções
> (como
> > a
> > > de rede por ex.) e o custo dos context switchs foram minimizados para o
> > > impacto ser pequeno, mas na verdade, não existe sistema multitarefa sem
> > > isso.
> > >
> > > No FreeBSD eu posso dizer que fazer o affinity para atendimento de irqs
> > da
> > > placas rede não muda muito (se é que muda alguma coisa)... Cada driver
> > > implementa a recepção de uma forma... alguns recebem efetivamente o
> > pacote
> > > quando a interrupção é disparada, mas a maioria dos drivers novos (1g e
> > 10g)
> > > apenas sinalizam o hardware com o ack da interrupção (que vai liberar o
> > > hardware para receber mais dados) e disparam um outro processo que vai
> > > realmente fazer a leitura dos dados recebidos pela placa (uma especie
> de
> > > polling).
> > >
> > > O importante Pina é a integração entre todos os subsistemas, não
> adianta
> > > priorizar uma coisa que depende de muitas outras...
> > >
> > > Ainda esses tempo o Sam Leffler do FreBSD comentou que o pessoal do
> Linux
> > > quase sempre chega querendo mudar o "sistema" de recepção de rede no
> > FreeBSD
> > > ala Linux... a maioria (senão todos) desistem depois de fazer testes no
> > > FreeBSD, o network stack é tão bem integrado que mesmo nessa loucura de
> > SMP
> > > o resultado acaba sendo no mínimo o mesmo senão superior a qualquer
> outro
> > > "approach".
> > >
> > > Claro que isso é diferente em roteadores dedicados, onde você pode ter
> > > quantas cpus precisar, dedicar elas para cada função e assim por
> diante,
> > bem
> > > diferente de um S.O. feito para funcionar com qualquer coisa.
> > >
> > > []'s
> > > Luiz
> > > PS: Se no Linux a performance é melhor eu realmente não sei e não posso
> > > dizer...
> > >
> > >
> > >
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
>
>
>
> --
> []'s
> Alfredo
> Bob Hope  - "You know you are getting old when the candles cost more than
> the cake."
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



More information about the gter mailing list