FOOD FOR THOUGHT Best Timing Source

[luckman212]

Sigh... I fiddled with knobs for about 6 hours, ran a battery of tests with all available clocksources (hpet, acpi_pm, tsc, jiffies, pit) and repeating each test at least 3 times to be sure. Each test was run for 5 minutes (dahdi_test -c 600). The results were horrible- totally inconclusive and only proved to me that there is no single reliable clocksource on this system whatsoever. I suppose if someone held a gun to my head, I would choose tsc, based on the results. Kind of funny that after all that, I wound up going back to the original, default PiaF clocksource. That was the only one that gave me a 'passable' score (>99.975).

Anyway, the table is below for anyone who cares. I took the best run from each clocksource and then reverse-sorted them by the best average score. I'd love to see results from some other SIP-only systems (w/o DAHDI hardware) to see if they are similarly horrid at keeping time.

So I wound up buying a cheap PCIe FXO/FXS card (TDM410e from Nicherons). Unfortunately this will not fit in my Acer Revo so I am now shopping for a new low power Atom system that has a single PCIe slot.

 

[Linetux]

Here's a test from a Supermicro Atom 330, 2.6.18-194.17.1.el5 - same box I use for a lot of PBX systems.

http://www.newegg.com/Product/Product.aspx?Item=N82E16816101262

This one doesn't have a hardware timing source at all.

$ dahdi_test
Opened pseudo dahdi interface, measuring accuracy...
99.995% 99.987% 99.992% 99.992% 99.991% 99.993% 99.992% 99.992%
99.715% 99.990% 99.993% 99.991% 99.992% 99.992% 99.992% 99.993%
99.991% 99.991% 99.894% 99.992% 99.993% 99.993% 99.992% 99.895%
99.991% 99.991% 99.992% 99.992% 99.895% 99.992% 99.617% 99.992%
99.993% 99.892% 99.993% 99.993% 99.990% 99.992% 99.894% 99.992%
99.992% 99.990% 99.993% 99.894% 99.617% 99.992% 99.992% 99.992%
99.893% 99.990% 99.992% 99.992% 99.993% 99.895% 99.992% 99.992%
99.993% 99.990% 99.715% 99.998% 99.982% 99.992% 99.993% 99.894%
99.993% 99.990% 99.991% 99.992% 99.894% 99.992% 99.992% 99.993%
99.992% 99.913% 99.992% 99.993% 99.992% 99.992% 99.911% 99.991%
99.991% 99.991% 99.992% 99.992% 99.992% 99.995% 99.990% 99.992%
--- Results after 88 passes ---
Best: 99.998 -- Worst: 99.617 -- Average: 99.964119, Difference: 99.998543

I'd say it's no better than your box software-wise.

This is another test box running off of ESX (non para-virtual).


$ zttest
Opened pseudo zap interface, measuring accuracy...
99.942284% 99.961327% 99.941498% 99.960938% 99.946686% 99.955856% 99.969734%
99.941803% 99.961128% 99.943268% 99.961426% 99.961235% 99.943848% 99.961029% 99.947456%
99.965729% 99.944916% 99.961617% 99.962112% 99.943748% 99.961136% 99.944138% 99.961128%
99.942764% 99.960449% 99.962700% 99.944626% 99.961815% 99.950188% 99.967384% 99.944626%
99.961327% 99.960648% 99.950394% 99.969528% 99.943558% 99.960938% 99.942383% 99.960556%
99.960938% 99.944145% 99.961327% 99.943657% 99.962601% 99.960449% 99.943367% 99.960838%
99.943459% 99.961426% 99.942680% 99.962006% 99.952843% 99.937401% 99.962402% 99.943367%
99.958290% 99.940140% 99.960938% 99.962303% 99.950005% 99.966705% 99.942871% 99.960938%
99.947952% 99.965134% 99.961723% 99.950195% 99.969040% 99.943260% 99.961136% 99.957619%
99.940430% 99.961624% 99.942688% 99.960541% 99.946487% 99.964264% 99.960449% 99.950485%
99.969734% 99.942383% 99.960449% 99.942482% 99.960449% 99.960258% 99.946388% 99.965729%
99.944626% 99.963966% 99.943855% 99.960747% 99.962509% 99.944435% 99.961922% 99.943947%
99.961624%
--- Results after 96 passes ---
Best: 99.970 -- Worst: 99.937 -- Average: 99.954495, Difference: 99.997982

And this is exactly why I don't put a box into production unless it's got a hardware timing source in it.

Anyone have results from a Proxmox VM they can share?

 

[dswartz]

Yes, I just completed a run:

Opened pseudo dahdi interface, measuring accuracy...
99.998% 99.621% 99.996% 99.606% 99.613% 99.605% 99.613% 99.606%
99.996% 99.994% 99.612% 99.604% 99.997% 99.613% 99.995% 99.997%
99.607% 99.995% 99.996% 99.996% 99.995% 99.995% 99.996% 99.996%
99.613% 99.605% 99.996% 99.996% 99.613% 99.996% 99.605% 99.613%
99.605% 99.996% 99.995% 99.995% 99.613% 99.605% 99.996% 99.996%
99.996% 99.613% 99.606% 99.983% 99.975% 99.995% 99.612% 99.605%
99.996% 99.615% 99.605% 99.613% 99.996% 99.606% 99.995% 99.996%
99.996% 99.997% 99.994% 99.996% 99.995% 99.995% 99.995% 99.996%
99.614% 99.605% 99.613% 99.996% 99.997% 99.996% 99.996% 99.996%
99.996% 99.995% 99.996% 99.995% 99.996% 99.996% 99.996% 99.996%
99.996% 99.996% 99.996% 99.996% 99.996% 99.996% 99.996% 99.996%
99.996% 99.996% 99.996% 99.996% 99.995% 99.996% 99.998% 99.996%
99.991% 99.995% 99.996% 99.996% 99.998% 99.998% 99.996% 99.996%
99.998% 99.998% 99.998% 99.996% 99.997% 99.996% 99.998% 99.996%
99.998% 99.997% 99.998% 99.998% 99.996% 99.997% 99.994% 99.997%
99.995% 99.996% 99.997% 99.998% 99.996% 99.996% 99.996% 99.995%
99.996% 99.997% 99.997% 99.996% 99.996% 99.998% 99.998% 99.996%
99.997% 99.995% 99.998% 99.996% 99.998% 99.998% 99.997% 99.998%
99.998% 99.996% 99.998% 99.997% 99.997% 99.998% 99.998% 99.996%
99.996% 99.996% 99.996% 99.996% 99.996% 99.996% 99.996% 99.997%
99.996% 99.996% 99.996% 99.996% 99.996% 99.997% 99.995% 99.996%
99.996% 99.996% 99.996% 99.996% 99.996% 99.995% 99.996% 99.995%
99.996% 99.996% 99.996% 99.996% 99.996% 99.995% 99.997% 99.996% ^C
--- Results after 184 passes ---
Best: 99.998 -- Worst: 99.604 -- Average: 99.935035, Difference: 99.998207

Amusingly, this has nothing to do with the PVM itself - I got virtually the same results in the HN itself. The host is using hpet.

 

[dswartz]

So here is an interesting question: the HN gets the same inconsistent numbers. e.g. mostly very good, with dribs and drabs of number in the 99.6xx range. res_timing_timerfd is certainly available on the host, yet dahdi_test uses the pseudo device - what does it use? If asterisk were able to use res_timing_timerfd, and the dahdi pseudo device doesn't, are the timing results I posted even relevant?

 

[elihunter]

I have a Supermicro Atom based system and am seeing the same issues with timing. My clients tell me voice quality has been very good but this is the first office using this server, we will eventually be adding more offices and I assume will start to see problems.

Has anybody had any luck with a Sangoma UT50? I can't find much mention of them on the forums here, I assume because they're not really supported with the 2.6.18 kernel. I may just have to risk it and buy one to test.

Here's my dahdi_test results from a 5 minute run using acpi_pm.

100.000% 99.994% 99.997% 99.998% 99.906% 99.999% 99.996% 99.998%
99.997% 99.897% 99.999% 99.996% 99.998% 99.997% 99.900% 100.000%
99.994% 99.995% 99.997% 99.710% 99.996% 99.998% 99.997% 99.998%
99.899% 99.995% 99.996% 99.997% 99.998% 99.901% 99.998% 99.996%
99.997% 99.899% 99.997% 99.998% 99.996% 99.998% 99.899% 99.997%
99.999% 99.994% 99.997% 99.710% 99.998% 99.997% 99.998% 99.997%
99.900% 99.996% 99.999% 99.996% 99.998% 99.900% 99.998% 99.999%
99.996% 99.997% 99.904% 99.993% 99.999% 99.996% 99.997% 99.899%
99.998% 99.997% 99.996% 99.612% 99.899% 99.998% 99.999% 99.996%
99.998% 99.897% 99.997% 99.999% 99.997% 99.998% 99.899% 99.998%
99.999% 99.992% 99.997% 99.900% 99.998% 99.999% 99.996% 99.611%
99.704% 99.995%
--- Results after 586 passes ---
Best: 100.000 -- Worst: 99.606 -- Average: 99.959197, Difference: 99.994549

 

[Linetux]

They're the next-best thing to hardware timing source (PRI card, etc). I have about 5 of them in production on various hardware.

It works fine with 2.6.18, but you might need to talk to Sangoma to get it working if you get stuck.

 

[luckman212]

I will be testing a UT51 (internal version of the UT50) shortly, expecting it to arrive early next week. Will definitely post the results here. Also have a TDM410P dahdi card on the way, so it will be interesting to compare the accuracy of those 2 sources.

 

[dswartz]

Keep us posted on the UT51...

 

[luckman212]

Well, they sent me the wrong part. Opened the box to find a UT50 inside, instead of the UT51 I was expecting. Oh well. Plugged it in anyway. Installing & compiling the wanpipe driver was pretty easy, restared DAHDI and there it was...

root@pbx:~ $ dahdi_test -c 60
Opened pseudo dahdi interface, measuring accuracy...
99.998% 99.992% 99.995% 99.996% 99.996% 99.996% 99.996% 99.996%
99.996% 99.994% 99.996% 99.996% 99.996% 99.996% 99.996% 99.996%
99.996% 99.994% 99.996% 99.996% 99.996% 99.997% 99.997% 99.997%
99.997% 99.994% 99.997% 99.996% 99.996% 99.996% 99.996% 99.997%
99.997% 99.994% 99.997% 99.996% 99.997% 99.996% 99.997% 99.996%
99.997% 99.994% 99.996% 99.996% 99.996% 99.996% 99.996% 99.996%
99.996% 99.994% 99.996% 99.996% 99.996% 99.995% 99.996% 99.996%
99.996% 99.994% 99.996%
--- Results after 59 passes ---
Best: 99.998 -- Worst: 99.992 -- Average: 99.995952, Difference: 99.995951

Of course this is a limited test, haven't really put it thru its paces yet or seen whether this has a positive effect on voice quality but the numbers look promising. Sleep now.

 

[Linetux]

FWIW, I only get the UT50's, as I can take an internal motherboard header to USB port (they come with a lot of motherboard kits for those that don't know) and then I just use double-stick tape to tape it to the inside of the case. That way it's out of the way and all that good stuff.

 

[dswartz]

so if i did get one of these, how do i ensure that asterisk is using it? when i look at my current timing source, it says asterisk is using the pthread timer, not the dahdi timer. is asterisk smart enough to use the dahdi timer if there is a good timing source attached to it? i know you can run dahdi_test and see what the ut5x is doing, but that doesn't mean that asterisk will automatically use it. or will it?

 

[randy7376]

Maybe this will help answer some of your questions...

https://wiki.asterisk.org/wiki/display/AST/Timing+Interfaces

 

[dswartz]

Hmmm, that's interesting. Thanks for the cite. That leaves me even more confused though. My piaf appliance does have dahdi available, but look:

pbx*CLI> module show like timing
Module Description Use Count
res_timing_dahdi.so DAHDI Timing Interface 0
res_timing_pthread.so pthread Timing Interface 3

So I have dahdi available, but it is using the pthread timer, which it shouldn't be, according to the doc you referred me to. I need to double-check some things - I wonder if asterisk thinks dahdi is not available for some reason?

 

[randy7376]

What about adding noload => res_timing_pthread.so to /etc/asterisk/modules.conf

2. Build, but do not load the timing modules you know you will not use. You can edit modules.conf using "noload" lines to disable the loading of specific timing modules by default. Based on the note in the section above, you may realize that your Asterisk setup does not require internal timing at all. If this is the case, you can safely noload all timing modules.

You could at least test your setup with the DAHDi timing, if that is what you're looking to do...

 

[luckman212]

Hmmm here I was happily thinking that since installing my UT50, and with those nice 99.99x test scores, that my asterisk was using DAHDI for timing.

well, that seems to not be the case:

pbx*CLI> module show like timing
Module                         Description                              Use Count
res_timing_pthread.so          pthread Timing Interface                 2        
1 modules loaded

Well that's because of the modules.conf forcing noload => res_timing_dahdi.so (to fix the silent MOH for Ast 1.8.x). So when I re-enable res_timing_dahdi then my MOH goes away again. Stuck!

 

[dswartz]

are you running an openvz container? if so, i just figured out what was wrong. i was following a howto which described how to get the /dev/dahdi/pseudo on the HN to be visible in the container. nowhere had i actually set up the other 3 dahdi devices, /dev/dahdi/channel, /dev/dahdi/timing and /dev/dahdi/ctl. I did that, restarted the container, and now:

pbx*CLI> module show like timing
Module Description Use Count
res_timing_dahdi.so DAHDI Timing Interface 1
res_timing_pthread.so pthread Timing Interface 0

 

[luckman212]

My issue isn't getting the dahdi timing module to load, it's just that when I *do* load it, my MOH stops working.

root@pbx:~ $ ls -al /dev/dahdi/
total 0
drwxr-xr-x  2 asterisk asterisk      120 Jan 11 11:15 .
drwxr-xr-x 12 root     root         3680 Jan 11 11:16 ..
crw-rw----  1 asterisk asterisk 196, 254 Jan 11 11:15 channel
crw-rw----  1 asterisk asterisk 196,   0 Jan 11 11:15 ctl
crw-rw----  1 asterisk asterisk 196, 255 Jan 11 11:15 pseudo
crw-rw----  1 asterisk asterisk 196, 253 Jan 11 11:15 timer

 

[dswartz]

ah, separate issue then. glad i haven't switched to 1.8 yet. i don't think the WAF would be acceptable yet.

 

[luckman212]

WAF? wife acceptance factor?

 

[dswartz]

bingo! my wife telecommutes, which means she needs to make a lot of conference calls. when i early on asked if it was okay to set up X or Y or Z, she just rolled her eyes and said 'as long as it works!'