Resumo. Objetivo. Introdução

Transcrição

1 Relatório sobre bechmark com computadores da NOVA. Resumo O presente relatório apresenta informações necessárias sobre aplicação de algumas técnicas para otimização e avaliação da performance do microcomputador CORE 2 QUAD Q6 - POTENCIALL da NOVA computadores. Objetivo Ter uma base inicial de dados sobre o consumo de processamento gerado pelos algoritmos de cancelamento de eco, transcodificação e sinalização SIP. Verificar os impactos causados no sistema quando o hardware estiver na sua capacidade máxima de utilização. Introdução Os critérios usados para avaliar o comportamento do sistema são o consumo de processamento, perda de IRQ, picotamento de voz nas ligações, erros de protocolo e erros do Asterisk. Os critérios foram definidos com base no consumo de processamento, pois é este o principal item que compromete a integridade das ligações e dos demais serviços do sistema. Entretanto, para monitorar o consumo de processamento foi necessário encontrar uma ferramenta que detalhasse os itens que geravam carga de processamento. A ferramenta utilizada foi o mpstat, ela consegue monitorar o consumo de IRQ, o consumo de sistema, de usuário, entre outros, além de mostra o consumo isoladamente entre os núcleos. Então, destacamos que o consumo gerado pela IRQ da placa de rede é o que mais consume carga. Pois dependendo do codec pode gerar em um ligação de 1 a interrupções por segundo, e esse valor multiplicado por uma quantidade elevada de ligações pode influenciar consideravelmente no consumo de processamento. Com isso, encontramos um nível mínimo para que o processador garanta a integridade voz nas ligações. O nível mínimo foi de 25% de IDLE em um dos núcleos, pois abaixo desse valor houve as primeiras perdas de pacotes e de IRQ da placa TDM (PXE), gerando picotamento da voz e atrasos. Para garantir um bom funcionamento no sistema como um todo 45% de IDLE é suficiente. Abaixo esta listado alguns aplicativos e ferramentas utilizadas nos testes: SIPP - Software para geração de trafego usando o protocolo SIP que possibilita a montagem de cenários (UAC, UAS) e estabelecimento de múltiplas chamadas. Pode ser baixado em: VMSTAT - comando para obter informações de memória, processador, HD) MPSTAT - comando mais detalhado que o vmstat memória tem a vantagem de verificar o consumo de carga de cada núcleo do processador. zttool ferramenta utilizada pelo zaptel para monitorar os troncos instalados, perdas de IRQ, violações bipolares. dahdi_tool -ferramenta utilizada pelo DAHDI para monitorar os troncos instalados, perdas de IRQ, violações bipolares.

2 1 - Configuração das maquinas: Servidor Disc-Os (servidor em teste). CORE 2 QUAD Q6 - POTENCIALL Hardware Placa mãe processador chipset cache L2 size Interface E1 Gigabyte ga-946gmds2 core 2 quad q6(2.4ghz) intel 946 8MB (4MB para cada 2 núcleos) PXE445 Maquina 1 geradora de chamadas SIP Software Sipp Ubuntu 7.4 Hardware Notebook satellite 2435 Processador: Pentium Ghz Maquinas Auxiliares SIP/TDM Software Disc-1. Hardware PC Nova Processador Pentium 4 3.Ghz PXE245 Maquina 2 atendedora de chamadas SIP Software Sipp Ubuntu 7.4 Hardware PC Nova POTENCIALL E4 Core 2 Duo E4 (1.8 Ghz) 2- Procedimentos de otimização: IRQ Para um melhor desempenho e otimização do microcomputador, devido a quantidade de requisições geradas pelas placas de rede e PXE, é realizado a divisão das IRQ's entre os núcleos do processador. A divisão de IRQ diminuí a possibilidade de perda de IRQ, garante uma melhor divisão da carga do sistema, oferece um ganho considerável de IDLE e possibilita uma melhor administração do sistema, ou seja, dificilmente encontrará o terminal travando enquanto um dos núcleos estiver sobre carregado. Para dividir as IRQ's entre os núcleos do processador, acesse o shell de root do servidor Disc-Os e realize os seguintes passos para trocar de núcleo a IRQ da placa PXE e de rede: Passo1 Visualize os arquivo /proc/interrrupts com o seguinte comando: #cat /proc/interrupts neste arquivo você encontra informações necessárias de qual IRQ está alocado para cada dispositivo. Irá aparecer o seguinte resultado: IRQ Devices : 1964 IO-APIC-edge timer 177: IO-APIC-level eth 185: 1 IO-APIC-level pxe Note que a placa PXE está na IRQ 185, gerando interrupções para a. Indicamos alocar a IRQ da placa PXE na 3 e a IRQ da placa de rede(eth) na 1, pois através de testes foi verificado que essa configuração apresentou os

3 melhores resultados. Para alterar a IRQ da placa PXE para o 3, execute o seguinte comando: Passo 2 # echo 8 > /proc/irq/185/smp_affinity 8 é o número hexadecimal correspondente a 3 (segue a tabela 1) e 185 é a IRQ da placa. Binário Hexadecimal TABELA 1 Obs: O procedimento da divisão de IRQ/Processador não é necessária para o CENTOS 5. É necessário instalar o pacote irqbalance. Para alterar a IRQ da placa de rede ETH para a 1, e execute o seguinte passo: #echo 2 > /proc/irq/177/smp_affinity Ulimit O Kernel contem uma limitação de quantidade de arquivos abertos, pois ao gerar uma certa quantidade de chamadas o kernel não consegue abrir mais portas RTP durante as chamadas. Execute os seguintes comandos para corrigir este problema: #Killall asterisk #ulimit -n #asterisk start desligar o asterisk define o valor de para arquivos abertos. Iniciar o asterisk 3- Algoritmos de cancelamento de eco testados: -KB1 -OSLEC - O KB1 foi base de desenvolvimento para o, que foi base para o desenvolvimento do OSLEC. KB1 Contém uma falha a qual não existe diferença de processamento com CE habilitado para 128 Taps e sem CE habilitados. Testes com KB1 foram realizados nas seguintes condições:

4 Cenário 1 Cenário 2 OpenR2 1. OpenR2 1. Zaptel DAHDI 2. Asterisk asterisk Disc 1.1 Disc-Os 1.5 Kernel smp Kernel smp O KB1 já nativo do pacote do zaptel , por padrão quando o zaptel é carregado no sistema o KB1 o CE utilizado. O KB1 está disponível nas versões do zaptel e DAHDI. OSLEC O OSLEC possui a flag SSE2 que incrementa 14 instruções, melhorando o desempenho do algoritmo. Os processadores da INTEL pentium 4 ou superior e Opteron da AMD oferecem suporte a SSE2. Para compilar o OSLEC com suporte a SSE2, realize os seguintes passos: $ svn co oslec # Realize o download do código. $ cd oslec/ # Entre no diretório oslec/ $ vim kernel/makefile # Edite o arquivo Makefile. Na seguinte linha adicione as flags -DUSE_SSE2: $(MAKE) -C $(KDIR) EXTRA_CFLAGS='$(KINCLUDE) -DUSE_SSE2 -DEXPORT_SYMTAB -O6' SUBDIRS=$(PWD) modules Salve e saia do arquivo, o próximo passo será compilar OSLEC: $ make Compila o código $ insmod kernel/oslec.ko Carrega o modulo Os testes com OSLEC foram realizados nas seguintes condições: -OpenR2 -Zaptel Asterisk Disc-Os 1.1 -Kernel smp O Oslec está disponível para algumas versões do zaptel(somente), mas é preciso instalar manualmente através de patch's, sendo possível nas seguintes versões: 1.4.3, , , , , 1.4.1, 1.4.4, , 1.4.8,

5 Testes com foram feitos nas seguintes condições: Plataforma 1 Plataforma 2 OpenR2 1. OpenR2 1. Zaptel DAHDI 2. Asterisk asterisk Disc 1.1 Disc-Os 1.5 Kernel smp 3 - Padrão para os testes Kernel smp Quantidade de ligação de 1x3 (um tronco E1 para três para ramais SIP) Cancelamento de eco de % ou 1% nos canais E1 % de transcodificação de G729 para G Configuração do asterisk Abaixo detalhamos a configuração para compilar os algoritmos de cancelamento de eco no zaptel e no DAHDI Zaptel Nas versões do zaptel para alterar o algoritmo de cancelamento a ser compilado execute os seguintes passos: Passo 1: #cd zaptel-1.x.x #vim zconfig.h ;acesse o diretório do source do zaptel ; edite o arquivo zconfig.h Por volta da linha 55, mostra os algoritmos disponíveis para compilação no zaptel: * Pick your echo canceller. * */ /* #define ECHO_CAN_STEVE */ /* #define ECHO_CAN_STEVE2 */ /* #define ECHO_CAN_MARK */ /* #define ECHO_CAN_MARK2 */ /* #define ECHO_CAN_MARK3 */ #define ECHO_CAN_KB1 /* is a version of KB1 that has some changes to it that are * supposed to improve how it performs. If you have echo problems, * try it out! */ /* #define ECHO_CAN_ */ No zaptel , fizemos testes com o KB1, Oslec e com o, por padrão o zaptel compila o KB1. Para alterar do KB1 para o, siga os seguintes passos: Passo 2 Desabilitando o KB1. Edite a seguinte linha: Antes: #define ECHO_CAN_KB1 Depois: */ #define ECHO_CAN_KB1 */

6 Passo 3 Habilitando o. Edite a seguinte linha: Antes: /* #define ECHO_CAN_ */ Depois: #define ECHO_CAN_ Passo 4 - Salve e saia do arquivo e execute os seguintes comandos para compilar o zaptel: #make #make install ; compila o zaptel ; instala os módulos Passo 5 edite o arquivo /etc/asterisk/zapata.conf echocancelechocancel= yes ( yes para 128Taps/16ms ou 256 para 256Taps/32ms) Passo 6 salve e saia do arquivo e reboot a maquina. # init 6 ;reboot a maquina 4.2- DAHDI No pacote do DAHDI, todos os algoritmos de CE são compilados (KB1,, SEC, SEC2). Por exemplo, para habilitar o nos 4 troncos de uma placa PXE 4E1, realize os seguintes passos: Passo 1- Abra o arquivo /etc/dahdi/system.conf e adicione as seguintes linhas: echocanceller=mg2,1-15,17-31 ;Habilitando nos canais do tronco 1 echocanceller=mg2,32-46,48-62 ;Habilitando nos canais do tronco 2 echocanceller=mg2,63-77,79-93 ;Habilitando nos canais do tronco 3 echocanceller=mg2,94-18, ;Habilitando nos canais do tronco 4 Passo 2 - Salve e saia do arquivo Passo 3 edite o arquivo /etc/asterisk/chan-dahdi.conf echocancel= yes ( yes para 128Taps/16ms ou 256 para 256Taps/32ms) Passo 4 salve e saia do arquivo e reinicie o servidor: #init 6 ; reinicia o servidor. 5 Cenário de teste de performance:

7 O cenário é constituído pela máquina 1 que gera ligações SIP com áudio, por 2 servidores E1, por um servidor PBX IP Disc-OS (servidor em teste) e pela máquina 2 para atender as ligações SIP e enviar pacotes de áudio. A máquina 1 inicializa a comunicação SIP com os servidores E1 auxiliares, eles fazem conversão de SIP/TDM e encaminham as chamadas pelos links E1 para o servidor PBX IP Disc-OS. O servidor PBX IP Disc-OS faz o roteamento das chamadas e repassa pela rede até a máquina 2 que atende as chamadas. Após realizada a troca de sinalização SIP, as maquinas (1 e 2) iniciarão o tráfego de pacotes de áudio com o codec G711 e G729 passando pelo servidor em teste. Os arquivos de áudio foram gerados para simularem um cenário real, ou seja, contém um arquivo com o áudio sem eco que é transmitido pela maquina 2 e um arquivo com áudio com eco que é transmitido pela maquina Comandos gerais para simular o teste de performance: Antes de iniciar os testes, realize os procedimentos abaixo: Depois de instalado o sipp, é necessário gerar um arquivo XML para poder transmitir tráfego RTP nos dois sentidos da chamada. Na maquina 1, usando o usuário root, digite: #sipp -sd uac_pcap > uac_pcap.xml Na maquina 2, usando o usuário root: #sipp -sd uas_pcap > uas_pcap.xml Abra o arquivo uas_pcap.xml e adicione as seguintes linhas inicio do documento: <send retrans="1"> <![CDATA[ REGISTER sip:[remote_ip] SIP/2. Via: SIP/2./[transport] [local_ip]:[local_port] To: <sip:sipp@[ip_servidor_de_registro]:> From: <sip:sipp@[ip_local]:> Contact: <sip:sipp@[ip_local]:>;transport=udp sipp Expires: 3 Call-ID: [call_id] CSeq: 1 REGISTER Content-Length: ]]> </send> Para adicionar o tipo de pacote RTP que ira trafegar na chamada, acesse o usuário de root da maquina 1 edite as seguintes linhas do arquivo uac_pcap.xml # vim uac_pcap_xml ; abrindo o arquivo  <nop> <action> <exec play_pcap_audio="/usr/local/share/sipp/libpcap/[arquivo_rtp]"/> </action> </nop> <pause milliseconds="1"/> ; [Arquivo_RTP]e o arquivo com pacotes RTP que ; ira trafegar após estabelecer a chamada. Neste ; item que deve ser alterado para transmitir o ; pacote Rtp desejado ; Tempo em milisegundos, deve ser de acordo ; com o tempo de transmissão de pacotes RTP. Para transmitir pacotes de audio RTP por mais tempo, basta copiar e colar o trecho acima para se repetir o processo. Na maquina 2, execute os seguintes passos para configurar a transmissão de RTP no

8 SIPP: Passo 1 Crie outro arquivo uas_pcap, que sera o arquivo para trafego de pacotes RTP. Como usuário de root execute o seguinte comando: #sipp -sd uas_pcap > uas_pcap1.xml Passo 2 Abra o arquivo uas_pcap1.xml e e edite as seguintes linhas: # vim uac_pcap1_xml ; abrindo o arquivo  <nop> <action> <exec play_pcap_audio="/usr/local/share/sipp/libpcap/[arquivo_rtp]"/> </action> </nop> <pause milliseconds="1"/> ; [Arquivo_RTP] Arquivo com pacotes RTP que ; ira trafegar após estabelecer a chamada. Neste ; item que deve ser alterado para transmitir o ; pacote RTP desejado ; Tempo em milisegundos, deve ser de acordo ; com o tempo de transmissão de pacotes RTP. Para transmitir pacotes de áudio RTP por mais tempo, basta copiar e colar o trecho acima para se repetir o processo: Realizando os testes: Na maquina 2 execute os seguintes os seguintes passos: Passo 1 - Comando para registro SIP da maquina 2 no servidor Disc-Os: #sipp -sf uas_pcap_xml l 1 Sintaxe do comando: sipp -sf [arquivo_uas_de_registro] [IP_servidor_de_registro] -l [quantidade_de_registros] Passo 2 - Comando para atendimento das chamadas e trafego RTP da maquina 2: sipp -sf uas_pcap.g711.xml s 1 -l 38 -d 1 -mi i Sintaxe do comando: sipp -sf [arquivo_uas_xml_com_áudio_rtp] [ip_destino] -s [numero_discado] -l [quantidada 1 realize os seguintes passos: Passo 3 Gerar 1 chamadas E1 com os seguintes comandos: sipp -sf uac_pcap_echo.g711.xml s 1 -l -d 1 -mi i sipp -sf uac_pcap_echo.g711.xml s 1 -l -d 1 -mi i Passo 4 gerar 1 chamadas SIP/G711 e chamadas SIP/729 com os seguintes comandos: sipp -sf uac_pcap_echo.g711.xml s 1 -l 1 -d 1 -mi i sipp -sf uac_pcap_g729.xml s 1 -l -d 1 -mi i É necessário verificar todas as maquinas durante e depois do estabelecimento das chamadas. Verifique se estão perdendo pacotes pela tela do SIPP e no servidor Disc-Os observe os seguintes itens:

9 Retransmissão de pacotes; Perda de IRQ das placas de rede e PXE ; Erros na troca de sinalização SIP e do E1; Perda de chamadas. E após dessa verificação é que se pode fazer uma avaliação o consumo de processamento e qualidade do áudio. e_de_chamadas] -d [tempo_duração_da_chamada] -mi [ip_de_tx_rtp] -i [IP_rx_RTP] Na maquina 1 realize os seguintes passos: Passo 3 Gerar 1 chamadas E1 com os seguintes comandos: sipp -sf uac_pcap_echo.g711.xml s 1 -l -d 1 -mi i sipp -sf uac_pcap_echo.g711.xml s 1 -l -d 1 -mi i Passo 4 gerar 1 chamadas SIP/G711 e chamadas SIP/729 com os seguintes comandos: sipp -sf uac_pcap_echo.g711.xml s 1 -l 1 -d 1 -mi i sipp -sf uac_pcap_g729.xml s 1 -l -d 1 -mi i É necessário verificar todas as maquinas durante e depois do estabelecimento das chamadas. Verifique se estão perdendo pacotes pela tela do SIPP e no servidor Disc-Os observe os seguintes itens: Retransmissão de pacotes; Perda de IRQ das placas de rede e PXE ; Erros na troca de sinalização SIP e do E1; Perda de chamadas. E após dessa verificação é que se pode fazer uma avaliação o consumo de processamento e qualidade do áudio. Resultados na pagina seguinte:

10 Cenario1 zaptel / Asterisk / openr2 1. / kernel Taps 1E1 + 3G711 Todos canais E1 com CE Oslec KB1 %idle %idle %idle all 83,63 all 84,25 all 82,17 1x3 9,13 Periféricos 89,31 Periféricos 87,39 Periféricos G ,58 Rede 1 63,1 Rede 1 61,68 Rede 1% CE 2 88,4 2 87, ,48 16ms(128Taps) 3 91,62 PXE 3 95,95 PXE 3 9,28 PXE 48portas Coluna H Taps 1E1 +1 G711 + G729 transcode g711 Todos canais E1 com CE Oslec KB1 %idle %idle %idle all 68,25 all 76,28 all 76,43 1x3 67,35 Periféricos 78,93 Periféricos 78,1 Periféricos G711 G ,71 Rede 1 49,48 Rede 1,93 Rede 1% CE 2 75, , ,76 16ms(128Taps) 3 87,2 PXE 3 94,51 PXE 3 93,52 PXE 48portas Coluna H Taps 1E1 + 3 canais E1 com CE Oslec KB1 %idle %idle %idle all 81,35 all 84,22 all 83,14 1x3 86,43 Periféricos 9,44 Periféricos 88,12 Periféricos G711 1,25 Rede 1 64,17 Rede 1 61,25 Rede % CE 2 86, , ,6 32ms(256Taps) 3 91,89 PXE 3 92,9 PXE 3 94,33 PXE 48portas Coluna H Taps 1E1 +1 G711 + G729 transcode g711 canais E1 com CE Oslec KB1 1x3 %idle %idle %idle G711 - G729 all 65,79 all 75,5 all 71,1 % CE 64,5 Periféricos 75,46 Periféricos 73,25 Periféricos 32ms(256Taps) 1 36,33 Rede 1 48,76 Rede 1 47,23 Rede 48portas 2 74,4 2 82, , ,83 PXE 3 92,87 PXE 3 86,6 PXE Coluna H 1 E1(128Taps) + E1(256Taps) +3 G711 Todos os canais com CE Oslec KB1 %idle %idle %idle 1x3 all 76,34 all 81,7 all 59,79 G711 86,97 Periféricos 85,95 Periféricos 78,74 Periféricos 1% CE 1 63,45 Rede 1 61,43 Rede 1 58,82 Rede 32ms(256Taps) 2 84, , ,2 16ms(128Taps) 3 7,16 PXE 3 91,28 PXE 3 24,8 PXE 48portas Coluna H 1

11 1 E1(256Taps) +18 G711 canais com CE Oslec %idle %idle all 92,32 all 92,33 1x3 98,76 Periféricos 97,73 Perifericos G ,26 Rede 1 79,22 Rede 1% CE 2 95, ,53 32ms(256Taps) 3 96,32 PXE 3 96,56 PXE 24portas % IDLE Oslec - E1(256Taps) +18 G711 - Todos os canais com CE Oslec %idle %idle all 89,86 all 9,52 1x3 95,45 Periféricos 96,46 Perifericos G ,56 Rede 1 75,88 Rede 1% CE 2 93, ,13 32ms(256Taps) 3 93,74 PXE 3 95,55 PXE 24portas % IDLE Cenario 2 dahdi-2. / asterisk / openr2 1. / kernel consumo Taps 1E1 + 3G711 Todos canais E1 com CE KB1 %idle %idle all 82,5 all 84,32 1x3 88,9 Perifericos 9,39 Periféricos G ,15 Rede 1 63,9 Rede 1% CE ,1 16ms(128Taps) 3 9,96 PXE 3 94,9 PXE 48portas % IDLE consumo 1 128Taps 1E1 +1 G711 + G729 transcode g711 Todos canais E1 com CE KB1 %idle %idle all 76,2 all 76,72 1x3 78,93 Perifericos 79,1 Periféricos G711 G ,55 Rede 1,12 Rede 1% CE 2 81, ms(128Taps) 3 94,52 PXE 3 95,66 PXE 48portas % IDLE

12 consumo 1 256Taps 1E1 + 3 canais E1 com CE KB1 %idle %idle all 83,71 all 84,65 1x3 89,47 Perifericos 92,37 Periféricos G Rede 1 66,19 Rede % CE 2 88, ms(256Taps) 3 95,39 PXE 3 93,3 PXE 48portas Taps 1E1 +1 G711 + G729 transcode g711 canais E1 com CE KB1 %idle %idle 1x3 all 71 all 75,26 G711 - G729 74,1 Periféricos 76,12 Periféricos % CE 1 43,29 Rede 1 47,79 Rede 32ms(256Taps) 2 79, ,1 48portas 3 86,9 PXE 3 93,13 PXE consumo 1 9 E1(128Taps) + E1(256Taps) +3 G711 Todos os canais com CE KB1 %idle %idle 1x3 all,94 all 81,57 G711 79,4 Periféricos 84,35 Periféricos 1% CE 1 59,3 Rede 1 63,45 Rede 32ms(256Taps) 2 78, ,48 16ms(128Taps) 3 27,3 PXE 3 91,98 PXE 48portas % IDLE Conclusão Os resultados das versões testadas ficaram próximos, mas observando com detalhes vemos um leve ganho de IDLE no Disc-Os 1.5, influenciado pelo asterisk 1.4 e pelo DAHDI. A Diferença pratica é que o DAHDI está em constante desenvolvimento e o zaptel não terá mais atualizações. O OSLEC no zaptel, apresentou um ótimo desempenho após compilado com a FLAG SSE2, se igualando ao consumo de processamento do KB1 e do. Contudo, nos testes é importante ressaltar que foi encontrado um problema na programação de reinvites, impossibilitando ter melhores resultados. Trabalhos futuros Falta avaliar se as diferentes versões do kernel produz ou não um melhor aproveitamento dos processadores com mais de um núcleo.