[GTER] RES: Quagga

[Antonio Carlos Pina]

netfilter padrãozão, full-routing recebido de 3 fontes.

Podemos fazer um lab e trazer mais informações.Mas o que observamos é que
trabalhando com polling, o poder da CPU é a primeira restrição (houve pouca
diferença sem e com netfilter). Imagino que ao quebrar a barreira de 1Mpps
aí a placa de rede+pci passem a ser o limitador.

Claro que não custa testar !

2009/4/1 Rubens Kuhl <rubensk at gmail.com>

> Pina,
>
> Essa performance é do netfilter padrão ou do nf-hipac ? (
> http://www.hipac.org/)
>
> Eu sempre tive curiosidade de comparar o hipac com o kernel
> "baunilha", e você e o Breno parecem ter levado essa questão a um
> nível muito bom. Uma apresentação no GTER com o conteúdo que vocês tem
> colocado nas mensagens é muito benvinda, aliás.
>
>
> Rubens
>
>
> 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
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>