SUGGESTIONS VM Timing

[Stewart]

System Stats

───────────────────────SYSTEM INFORMATION───────────────────────────┐
│ Asterisk = ONLINE | Dahdi = ONLINE | MySQL = ONLINE │
│ SSH = ONLINE | Apache = ONLINE | Iptables = ONLINE │
│ Fail2ban = ONLINE | Internet = ONLINE | Ip6Tables = ONLINE │
│ Disk Free = ADEQUATE| Mem Free = ADEQUATE| NTPD = ONLINE │
│ SendMail = ONLINE | Samba = OFFLINE | Webmin = ONLINE │
│ Ethernet0 = ONLINE | Ethernet1 = N/A | Wlan0 = N/A │
│ │
│ PIAF Installed Version = 2.0.6.3 under *VIRTUALBOX* │
│ FreePBX Version = 2.11.0.2 │
│ Running Asterisk Version = 11.1.2 │
│ Asterisk Source Version = 11.1.2 │
│ Dahdi Source Version = 2.6.1 │
│ Libpri Source Version = 1.4.12 │
│ IP Address = 192.168.0.157 on eth0 │
│ Operating System = CentOS release 6.3 (Final) │
│ Kernel Version = 2.6.32-279.14.1.el6.i686 - 32 Bit │
│ Incredible Version = 11.1.2

What is a good timing source to run inside of a VM?
Running: cat /sys/devices/system/clocksource/clocksource0/available_clocksource
Results in: tsc acpi_pm

Connected to Asterisk 11.1.2 currently running on pbx (pid = 1505)
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 0
res_timing_timerfd.so Timerfd Timing Interface 1
3 modules loaded
pbx*CLI>

I know timing is critical and in hardware boxes I use UT51 USB sticks. What is available in a VM? The focus is 25 users or less with less than 10 concurrent calls. I've run a few informational timing accuracy tests to give me an idea of what I can expect.

The Test Host is Win7 / WD 320GB HDD / Athlon II X4 630 (4 cores 2.81GHz) / 8GB RAM.
The Test Platform is Oracle VM / Single Core / 1GB RAM

State.........................................# Passes Best Worst Average Cumm Accuracy
Idle...............................................2009 100 97.328 99.846 99.957
Running Prime95........................1680 100 93.496 99.799 99.949
Running HD Tune.......................1109 100 97.553 99.843 99.957
Running Prime95+ HD Tune.....2348 100 95.293 99.817 99.947

Minimums..................................................93.496 99.799 99.947


What can be done in a VM to improve accuracy? TIA!

 

[arad85]

I'd not want to use a VM for timing-critical issues. Why not use an external analog(ue) gateway with the VM and treat all analog(ue) channels as SIP channels?

 

[Stewart]

I'm not following so I'm not seeing how it would help. Those would still be trunks that come in to the PBX in a VM that would need timing. I realize that the chart didn't come over very well, so I've cleaned it up. Usually for analog we just use the Grandstream GXW-4108 and it has worked fairly well for our clients. That still doesn't help with the fact that the Min timing on the PBX is < 99.75% (The minimum target) or that the Avg timing on the PBX is < 99.95% (the other target).

Could you clarify what you are trying to say? Thanks.

 

[arad85]

My understanding is that the timing constraints are only important for internal cards. Once you move to external gateways, you have much lower requirements on any real time processing. The test you were running has dahdi in the command name meaning it is relevant to analogue plugin cards...

 

[arad85]

I.e. I don't think the timing has any influence when you are running something like the gateway you normally use...

 

[phoneguy]

Wow lots of bad advice here.

1- Asterisk still needs real timing regardless of the trunks you are using.
2- Meet Me conferences need it
3- Paging needs it unless you are using app_conference.
4- MoH needs it to get proper timing regardless of the conference server you are using.

Those results you have posted are very poor and will result in issues with call quality.

 

[arad85]

On a quest for information here...

Wow lots of bad advice here.

1- Asterisk still needs real timing regardless of the trunks you are using.
2- Meet Me conferences need it
3- Paging needs it unless you are using app_conference.
4- MoH needs it to get proper timing regardless of the conference server you are using.

Those results you have posted are very poor and will result in issues with call quality.

What does it need accurate timing for? My understanding was that it was needed for interfacing to analogue cards, but once everything is in IP packets, I don't understand why you'd be worried by that level of timing... (if you can point me at anything online which explains it, that would be great....)

 

[Stewart]

Tony, that's my point. My PBXs are all SIP only with external gateways as needed, but I'm concerned about conferences and such as you pointed out.

Arad85, timing is like synchronization. If in a conference or paging, all of the audio needs to be synchronized for things to sound proper. You can't have different paging speakers saying the same thing at slightly different times. It would sound awful. Similar idea for conferences. Not so sure about why it's important with MoH, but I believe it would be similar to standard RTP in calls with the 20ms packets needing to be exact.

That makes my question all the more relevant. How do we improve timing in a VM environment. If there PIAF has VM distros now, I'd assume some work has been made on that front. Last time I tried a couple of years ago it just wasn't viable.

 

[arad85]

Arad85, timing is like synchronization. If in a conference or paging, all of the audio needs to be synchronized for things to sound proper. You can't have different paging speakers saying the same thing at slightly different times. It would sound awful. Similar idea for conferences. Not so sure about why it's important with MoH, but I believe it would be similar to standard RTP in calls with the 20ms packets needing to be exact.

So... how do you account for network delays? Packet delivery to two separate systems cannot be synchronous as network delays are never guaranteed. And if the systems are remote, the delays will not be noticed. Or they can be - I do a lot of worldwide conferencing and there can be terrible delays there.

As I said, my understanding was the timing was needed to use the analog(ue) sections of the card which just don't exist when you are using gateways - I think the program you are using is called dahdi_test - which I thought was simply to test the dahdi timing.

Just run it here (I have 1 core of an i5-3470S running my asterisk VM - which only gets occasional light use as it is a home system) and I get:

--- Results after 75 passes ---
Best: 100.000% -- Worst: 99.705% -- Average: 99.975232%

Cummulative Accuracy (not per pass): 99.998

Never perceived any call issues, but I don't use the system for any of the features that Tony mentioned. But people seem to run asterisk OK in VMs.

I just wouldn't use a VM to run anything timing critical - you have an O/S scheduling another O/S on top. What could possibly go wrong?

 

[arad85]

PS. On a quest for further information, I came across this: https://wiki.asterisk.org/wiki/display/AST/Timing+Interfaces

In which it says:

The only functionality that requires internal timing is IAX2 trunking. It may also be used when generating audio for playback, such as from a file. Even though internal timing is not a requirement for most Asterisk functionality, it may be advantageous to use it since the alternative is to use timing based on incoming frames of audio. If there are no incoming frames or if the incoming frames of audio are from an unreliable or jittery source, then the corresponding outgoing audio will also be unreliable, or even worse, nonexistent. Using internal timing prevents such unreliability.

and

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 safelynoload all timing modules.

 

[Stewart]

The network delays are handled by the jitter buffer. Most devices such as SIP phones have a jitter buffer built into them so it doesn't need to be set in Asterisk. But that is a handy link and makes me rethink what timing actually does. If it's purely SIP and meet-me now uses conf-bridge instead of dahdi, then dahdi is essentially moot. I have a contact at a very large organization that has an Asterisk Conference Bridge with over 350 rooms running on a VM that has no problems. I'm going to see if they can run some tests and tell me what they get. It's a 1.4.2(something) box so it should have Dahdi. I'll let you know what I find.

 

[arad85]

The network delays are handled by the jitter buffer.

Yes, that was my point (my question was rhetorical - not literal - that wasn't clear sorry) - why do you need accurate timing if you have buffers everywhere. You know you need x (don't know the number) samples for each coded frame, so you don't need timing information to generate that once digital. The other end deals with presenting it to the user at an appropriate rate. Don't get me wrong, the system needs to have a good enough clock to be able to make sure it is within tolerances, but - for example - I have a fairly low ping time to my ISP of ~10ms. The system has to be tolerant of timing issues way above that - so knowing you are within 0.01% of a nominal 8000Hz appears pretty irrelevant.

I'll let you know what I find.

Good stuff

 

[Stewart]

The boss OKed my request, but the server team apparently needs to get to it. Likely won't be until next week, though.

 

[Stewart]

Played like a violin. Guess they won't run the tests after all..