定时对于 Asterisk 中的某些类型的应用程序来说非常重要。如果 DAHDI 是定时源，则dahdi_test可以使用该命令检查 DAHDI 内核模块提供的定时。如果dahdi_test仅返回 99.975% 以上的测量值，则通常认为 DAHDI 定时源是好的。
从 Asterisk 1.6 开始，新的计时源已经可用，例如pthread和timerfd，它们在不使用或无法使用 DAHDI 硬件进行计时的系统中非常有用，因为它们代表了对模块的改进dahdi_dummy。显然，如果不使用 DAHDI 计时，则dahdi_test测试计时源将毫无用处；但任何计时源的准确性似乎都可以使用 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
我担心的是，计时 50 个刻度似乎比dahdi_test8000 毫秒内有 8192 个样本，特别是因为几乎每个我尝试过的系统，无论是虚拟的还是其他的，都可以处理它。
我可以要求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
根据我使用的系统，这确实会有点问题，通常计时器滴答声会减少。但我不确定将其强调到这个水平是否有用。
是否有关于使用和解释timing test命令的权威指导，以确保给定的 Asterisk 系统具有能够正常工作的计时源？
答案1
我意识到这是一个老问题，但对于任何来自谷歌的人来说：我的理解是，如果你的主板内置有高频计时源（很多都有），只要在 BIOS 设置中启用它，Linux 内核就会知道它，并且 timerfd 的性能应该和其他任何东西一样好。
我在 CentOS 6.5 上使用 Asterisk，在 VMware ESXi 5.5 中，硬件版本 10（虚拟机配置中将延迟敏感度设置为高），并安装了 vmware-tools-esx-nox RPM，使用 timerfd 获得了出色的性能。因此，这没有“真实的”物理 HF 计时源。Asterisk 在旧版本的 vmware 上表现糟糕，但总体而言，虚拟化已经取得了长足的进步。
答案2
如果你正在寻找有关 Asterisk 的所有信息的权威来源，那么 wiki 位于http://www.voip-info.org/就我的经验而言，这是最接近的了。Digium 也有自己的论坛，但不一定有 voip-info.org 上能找到的大量信息。
至于 Asterisk 命令行上的计时测试命令，除了确保您的 DAHDI 设备正常运行之外，我并不认为这是一个有意义的测试。如果卡上有故障，它可能会显示一些信息，但在我们完美运行的 Asterisk 交换机上，它每天路由大约 8000 个呼叫，运行“计时测试”时，任何超过 1000 的值都只会返回 1001 个计时器滴答（例如，即使请求 2048 个滴答）。在执行此操作的同时收听正在进行的呼叫不会导致语音质量下降，因此我不会将其称为任何类型的压力测试。
根据我们的经验，任何具有硬件回声消除功能的 Digium 卡都可以处理负载，但 Asterisk 的不足之处在于它承受着 SIP 呼叫和注册的压力。我们发现许多版本的 Asterisk 根本不够稳定，无法用于生产，即使是所谓的“发布”版本也是如此。测试这种情况的一种方法是使用 SIPp 负载测试器，配置和安装的详细信息可以在此处找到：http://www.loho.co.uk/blog/2011/08/sip-load-testing-with-sipp/。
然而，我们强烈建议使用 Debian-Stable 及其 Asterisk 二进制包，或者使用与它们完全相同的版本（可在此处找到：http://packages.debian.org/wheezy/asterisk）我们在几台 PBX 上都取得了成功，其中一些 PBX 的负载相当高（尽管没有我们主服务器的负载高 - 它们通常部署在客户站点）。