[GTER] RES: Quagga

Rubens Kuhl rubensk at gmail.com
Wed Apr 1 13:43:41 -03 2009


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
>



More information about the gter mailing list