Interpretação e uso do comando “teste de tempo” do Asterisk

Question

O tempo é muito importante para determinados tipos de aplicativos no Asterisk. Se DAHDI for a fonte de tempo, o comando dahdi_test pode ser usado para verificar o tempo fornecido pelo módulo do kernel DAHDI. Se dahdi_test retornar exclusivamente medições acima de 99,975%, a fonte de tempo DAHDI é geralmente considerada boa.

Desde o Asterisk 1.6, novas fontes de tempo estão disponíveis, como pthread e timerfd , que são úteis em sistemas que não usam ou não podem usar o hardware DAHDI para tempo, pois representam uma melhoria em relação ao dahdi_dummy módulo. Obviamente, se o tempo DAHDI não estiver sendo usado, dahdi_test não será útil para testar a fonte de tempo; mas a precisão de qualquer fonte de tempo parece ser mensurável com o comando Asterisk CLI timing test :

localhost*CLI> timing test
Attempting to test a timer with 50 ticks per second.
Using the 'timerfd' timing module for this test.
It has been 1000 milliseconds, and we got 50 timer ticks

Minha preocupação é que o tempo de 50 ticks parece ser um teste consideravelmente menos estressante do que as 8192 amostras de dahdi_test em 8000 ms , especialmente porque quase todos os sistemas que eu experimentei, virtuais ou não, podem lidar com isso.

Eu posso pedir ao timing test para aumentar o que eu considero como os padrões de dahdi_test :

localhost*CLI> timing test 1024
Attempting to test a timer with 1024 ticks per second.
Using the 'timerfd' timing module for this test.
It has been 1000 milliseconds, and we got 1024 timer ticks

Isso realmente vai quebrar um pouco, dependendo do sistema que estou usando, geralmente com uma diminuição nos ticks do timer. Mas não tenho certeza se isso é útil para enfatizá-lo a este nível.

Existe uma orientação autoritária sobre como usar e interpretar o comando timing test para garantir que um dado sistema Asterisk tenha uma fonte de tempo que funcione bem?

    

Answer 1

Eu percebo que essa é uma pergunta antiga, mas para qualquer outra pessoa que vem do google: entendo que sua placa-mãe tem uma fonte de temporização de alta frequência embutida (muitos fazem) e desde que esteja ativada nas configurações da BIOS, o kernel do Linux saberá sobre isso, e o timerfd deverá funcionar tão bem quanto qualquer outra coisa.

Tenho excelente desempenho com o timerfd usando o Asterisk no CentOS 6.5, dentro do VMware ESXi 5.5, versão de hardware 10 (com sensibilidade de latência definida como Alta na configuração da máquina virtual) e VMware-tools-esx-nox RPMs instalados. Então, isso é sem uma fonte de tempo real e física de HF. O Asterisk costumava ser terrível em versões mais antigas do VMware, mas a virtualização em geral já percorreu um longo caminho.

    

Answer 2

Se você está procurando uma fonte canônica de informações sobre todas as coisas do Asterisk, então o wiki no link é sobre como perto como vem, na minha experiência. A Digium também tem seus próprios fóruns, mas não necessariamente o tesouro de informações que você pode encontrar em voip-info.org.

Quanto ao comando de teste de tempo na linha de comando do Asterisk, eu realmente não chamaria isso de um teste significativo para muito além de garantir que seu dispositivo DAHDI esteja operando. Se houver uma falha na placa, ela poderá mostrar algo, mas no nosso perfeitamente funcional switch Asterisk, que está roteando cerca de 8000 chamadas por dia, executando 'teste de temporização' com qualquer valor acima de 1000, retorna nada mais que 1001 temporizadores (mesmo solicitando 2048 ticks, por exemplo). Ouvir uma chamada em andamento enquanto isso não resulta em nenhuma degradação da qualidade de voz, então eu não chamaria isso de nenhum tipo de teste de estresse.

Em nossa experiência, qualquer cartão Digium em funcionamento com cancelamento de eco de hardware lidará com a carga, mas onde o Asterisk cai é quando ele é enfatizado com chamadas e registros SIP. Descobrimos que muitas versões do Asterisk simplesmente não são estáveis o suficiente para uso em produção, mesmo supostamente versões "lançadas". Uma forma de testar essa condição é com o testador de carga SIPp, os detalhes para configuração e instalação podem ser encontrados aqui: .

No entanto, recomendamos que você use o pacote binário do Debian-Stable e do Asterisk, ou a mesma versão que eles usam (encontrada aqui: link . Tivemos um bom sucesso com isso em vários PBXs, alguns dos quais tiveram carga bastante alta (embora não tão altos quanto nosso servidor principal - eles geralmente são implantados em sites de clientes).