DAHDI Hardware for Timing Source

Asterisk Asterisk Support
1

I’m currently running several Asterisk 1.8 servers and timing is provided by res_timing_dahdi without DAHDI hardware. To improve call quality I want the servers to use DAHDI hardware based timing and I’m thinking of installing perhaps a TDM400 Series card in each server and configuring the server to use that as the timing source. Since I’m only going to be using the hardware for timing there’s no point in paying for something with features that aren’t going to be used. So, what’s the cheapest (but good quality) piece of hardware I can use for this?

I also have some Asterisk 1.8 servers with ISDN cards in them (Sangoma A104d). I assume Asterisk is using these for timing - how can I confirm this (i.e. that they aren’t using dahdi_dummy)?

2

  1. why do you think it will be better?

  2. current versions of dahdi implement the fallback timing in the driver core, so do not use dahdi_dummy for that. I think dahdi show channels will give the best available information. I’m not sure if this is the case for conference bridging (meetme).

3

Thanks for the response. For the first one I’ll respond with a question - why don’t you think it will be better? When I run dahdi_test on a server with an ISDN card I can see the timing is far more accurate and doesn’t drop below 99.975% whereas for those servers that don’t have any DAHDI hardware it regular drops below this ‘critical’ threshold. I better add that all of the Asterisk servers are physical and none are virtual machines. A lot of the issues I’m experiencing seem to be related to call quality with random audio drop outs, volume fluctuations, and one-way audio especially at high call volumes. I suppose I could also ask the question - what are all the problems that can occur when a server running Asterisk is given an inaccurate timing source?

With regards to the second one can you elaborate on ‘driver core’ v ‘dahdi_dummy’? I’ve done a few ‘core show channel xxxx’ on the ISDN servers and yes it does provide lots of information but I can’t find a particular variable which specifically tells me ‘yes, this server is using the ISDN card for timing’.

4

In older versions of dahdi, there was a device specific, independently loadable, sub-driver for the dummy device. Now, at least for timing, there is no such sub-device. The main module provides the fallback timing.

I don’t have real dahdi hardware, and with the demise of dahdi-dummy, I can’t check where the selected timing span is displayed other than reading the source code.

5

I wanted to add some clarifying notes.

First, with regard to telling which span is the “selected timing span”, it is possible to look in /proc/dahdi/ to determine if a span is the “MASTER” span or not. The master span in DAHDI is the span that controls mixing audio for all the other spans / pseudo channels, and there is only 0 or one MASTER span in the system.

For example, on a system that I have in the lab here with two single span cards:

 # head -1 /proc/dahdi/1
Span 1: WCT13x/0 "Wildcard TE133 Card 0" ESFB8ZS/ RED ClockSource 
# head -1 /proc/dahdi/2
Span 2: WCT1/0 "Wildcard TE121 Card 0" (MASTER) ESFB8ZS/ RED ClockSource

I can see that span 2 is the master span and is performing all audio mixing. As an aside, the “ClockSource” string is only significant on multiport cards and is used to indicate which span is the clocksource for the other ports on the card. This is different than the global “MASTER” span.

Early versions of DAHDI dummy could result in audio problems since it was expected that the kernel timer would fire regularly. If the kernel ever missed a timer tick audio would not be mixed properly. Newer versions of DAHDI (certainly 2.4+ perhaps earlier versions) updated DAHDI dummy to use the system clock and keep track of how much audio it needed to mix at every interval, therefore minor jitter in timer interrupt service times would not result in audio problems.

All the features of dahdi dummy were moved directly into the core of DAHDI so that dahdi would always be able to mix audio for pseudo channels regardless of the hardware configuration. DAHDI will now use a hardware timing source if one is available, or use the system clock on the system if one is not available. This means though that the host computer needs to have a good system clock.

In DAHDI 2.7.0+ the core timer in DAHDI supports the “monotonic” clock. This means that DAHDI is immune to system environments where ntpdate is run regularly to update the system clock. Previously this could cause problems because if DAHDI sees the wall clock jump by several seconds it would potentially drop audio.

Finally, when using core timer the dahdi_test results, depending on how the kernel is configured, can appear worse for each individual sample, but will be correct overall.

For example on a system with 10 ms timeslices (CONFIG_HZ=100):

# dahdi_test -c 5 -vv
Opened pseudo dahdi interface, measuring accuracy...

8192 samples in 8159.488 system clock sample intervals (99.603%)
8192 samples in 8159.376 system clock sample intervals (99.602%)
8192 samples in 8239.601 system clock sample intervals (99.419%)
8192 samples in 8159.640 system clock sample intervals (99.605%)
8192 samples in 8239.624 system clock sample intervals (99.419%)
--- Results after 5 passes ---
Best: 99.605% -- Worst: 99.419% -- Average: 99.529490%
Cummulative Accuracy (not per pass): 99.994

And on a system with 1ms timeslice (CONFIG_HZ=1000):

# dahdi_test -c 5 -vv
Opened pseudo dahdi interface, measuring accuracy...

8192 samples in 8191.952 system clock sample intervals (99.999%)
8192 samples in 8191.768 system clock sample intervals (99.997%)
8192 samples in 8191.928 system clock sample intervals (99.999%)
8192 samples in 8191.953 system clock sample intervals (99.999%)
8192 samples in 8191.904 system clock sample intervals (99.999%)
--- Results after 5 passes ---
Best: 99.999% -- Worst: 99.997% -- Average: 99.998789%
Cummulative Accuracy (not per pass): 99.999

In both cases the Cummulative Accuracy is better than 99.99%. This is the number that you’re most interested in since it accounts for jitter on the host.

Probably more information than you wanted, but the point of all this is that for recent versions of DAHDI with a properly configured system clock I do not see a need to purchase hardware just for timing.

6

Thanks for the reply. No, not at all, the more detail the better. I can confirm that for the servers with ISDN cards Asterisk is using the cards for timing. So, I guess my next question is what consitutes a ‘properly configured system clock’? How do I configure my system clock ‘properly’ or check that it is? You make an interesting point about the newer versions of DAHDI (2.7.0+) being more robust. Both the servers with and without ISDN cards are on DAHDI version 2.6.1 but the ‘cummulative accuracy’ doesn’t drop below 99.975% on those servers with the cards. I suppose the next step is to upgrade the servers without cards to the latest DAHDI version and see if it improves the ‘cummulative accuracy’ reading.

7

You do not want your system to have a wildly drifting clock. If your system clock is drifting you would notice that every day your system’s clock is off by several seconds. Also you don’t want ntpdate run in a frequent cron job to account for this.

The easiest way to ensure that the clock is slewed properly is to setup ntpd which will then tune the system’s understanding of the accuracy of the system clock over time and adjust it.

If your system is loaded when you’re running dahdi_test you could be seeing dahdi_test scheduling jitter as well. If so, you may be able to get more accurate results by ensuring that dahdi_test is running in a “realtime” priority class like:

chrt -f 99 dahdi_test -c -vv