对于Asterisk中某些types的应用来说， 时序是非常重要的。 如果DAHDI是定时源，则可以使用dahdi_test命令来检查由DAHDI内核模块提供的定时。 如果dahdi_test返回99.975％以上的测量值，DAHDI定时源通常被认为是好的。
自Asterisk 1.6以来，已经有了新的定时源，例如pthread和timerfd ，这些系统在没有或不能使用DAHDI硬件进行定时的系统中很有用，因为它们代表了对dahdi_dummy模块的改进。 显然，如果没有使用DAHDI时序， dahdi_test将不会用于testing时序源; 但任何时序源的精确度似乎都可以通过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
我担心的是， 在8000毫秒的时间内，50个时钟的计时似乎比dahdi_test的8192个样本要dahdi_test ，特别是因为几乎所有我尝试过的系统都可以处理它。
我可以要求timing test以达到我认为是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
这确实会因为我使用的系统而有所降低，通常会减less计时器滴答声。 但我不确定这是否有助于把它强调到这个水平。
是否有使用和解释timing test命令的权威性指导，以确保给定的Asterisk系统有一个定时源将运行良好？
我意识到这是一个古老的问题，但对于从谷歌来的任何人：这是我的理解，如果你的主板有一个内置的高频率定时源（很多），只要它在BIOS中启用设置，Linux内核会知道它，而timerfd应该和其他任何东西一样。
在CentOS 6.5，VMware ESXi 5.5内部，硬件版本10（在虚拟机configuration中将延迟敏感度设置为“高”）以及安装了vmware-tools-esx-nox RPMs的计算机上，使用timerfd可获得出色的性能。 所以，这没有一个“真正的”，物理高频时钟源。 Asterisk在老版本的vmware上曾经糟糕透顶，但是一般来说虚拟化已经有了很长的路要走。
如果您正在寻找关于Asterisk的所有信息的标准来源，那么根据我的经验， http: //www.voip-info.org/上的wiki就近似于它。 Digium也有他们自己的论坛，但不一定是你可以在voip-info.orgfind的信息库。
至于Asterisk命令行上的定时testing命令，除了确保您的DAHDI设备正在运行之外，我不会真正调用这个有意义的testing。 如果卡上有故障，它可能会显示一些东西，但是在我们完美工作的Asterisk交换机上，每天发送大约8000个呼叫，运行超过1000的任何值的“计时testing”将只返回1001个计时器滴答（偶数请求例如2048个滴答）。 在接听电话的过程中，不会导致语音质量的下降，所以我不会称之为任何压力testing。
根据我们的经验，任何带有硬件回声消除function的Digium卡都可以处理负载，但Asterisk掉落的地方是SIP呼叫和注册时的压力。 我们发现许多版本的Asterisk对于生产使用来说都不够稳定，甚至可能是“释放”版本。 testing这种情况的一种方法是使用SIPp负载testing仪，configuration和安装的细节可以在这里find： http : //www.loho.co.uk/blog/2011/08/sip-load-testing-with -sipp / 。
不过，我们强烈推荐使用Debian-Stable及其Asterisk二进制包，或者使用完全相同的版本（在这里可以find： http : //packages.debian.org/wheezy/asterisk ）。 在几个PBX上，我们取得了很好的成功，其中一些PBX有相当高的负载（虽然不如我们的主服务器高 – 通常部署在客户站点）。