FOOD FOR THOUGHT Best Timing Source

dswartz

Guru
Joined
Feb 17, 2009
Messages
1,056
Reaction score
0
well, here is the latest: sangoma says that i need to prove this happens with a stock 2.6.32 kernel, not just the proxmox version, before they will invest engineering cycles in it (I can't say I blame them.) Since I have not had a problem with voice quality, I think it's best I cut bait and move on. I will be putting the ut51 up for sale in the appropriate place here.
 

Linetux

Guru
Joined
Oct 5, 2008
Messages
541
Reaction score
1
Another timing test (pulling older hardware out of the closet) - this is a Rhino Ceros box. I just put PIAF Bronze on it for this test - no users, no extensions, no traffic.


$ dahdi_test
Opened pseudo dahdi interface, measuring accuracy...
99.998% 99.998% 99.999% 99.999% 99.999% 99.999% 99.999% 99.998%
99.998% 99.998% 100.000% 99.999% 99.999% 99.999% 99.999% 99.999%
99.999% 99.999% 99.999% 99.999% 99.999% 99.998% 99.999% 99.999%
99.999% 99.999% 99.999% 99.999% 100.000% 100.000% 100.000% 100.000%
100.000% 100.000% 100.000% 100.000% 100.000% 100.000% 99.998% 99.998%
99.997% 99.999% 100.000% 100.000% 99.999% 100.000% 100.000% 100.000%
100.000% 100.000% 99.999% 100.000% 100.000% 100.000% 99.999% 100.000%
99.999% 100.000% 100.000% 100.000% 99.999% 100.000% 99.999% 99.999%
100.000% 100.000% 100.000% 100.000% 100.000% 100.000% 100.000% 100.000%
100.000% 100.000% 100.000% 100.000% 100.000% 100.000% 100.000% 100.000%
99.998% 99.997% 99.998% 100.000% 100.000% 99.999% 100.000% 100.000%
100.000% 100.000% 99.999% 99.999% 99.999% 99.999% 99.999% 99.999%
99.999% 99.999% 99.999% 99.999% 99.999% 99.999% 99.999% 99.999%
99.999% 99.999% 99.999% 99.999% 99.999% 100.000% 99.999% 99.999%
99.999% 99.999% 99.999% 99.999% 99.999% 99.999% 99.999% 99.999%
99.999% 99.998% 99.997% 99.997% 99.998% 99.999% 99.999% 99.999%
99.999% 99.999% 99.999% 99.999% 100.000% 99.999% 99.999% 99.998%
99.999%
--- Results after 137 passes ---
Best: 100.000 -- Worst: 99.997 -- Average: 99.999162, Difference: 99.999714


This is running off a single-core AMD Athlon 3800+. The best scores I've seen yet.
 

kflorian

Member
Joined
Feb 18, 2010
Messages
76
Reaction score
4
luckman212,
I've lost track of exactly what you are trying to configure.

I'd like to get this all running in an ESXI 4.1 environment.

Here's an offer for you. I have a brand new shiny UT50. I lack any useful centos experience. While everything appears to build properly according to Sangoma's website, I'm certain the Sangoma is not being seen used...even though I see in the boot sequence that the usb device is being passed through properly by ESXI and "recognized" in some fashion by centos.

You can borrow the UT 50. If you get it working, tell me what you did.

Let me know if you're interested.

Ken
 

dswartz

Guru
Joined
Feb 17, 2009
Messages
1,056
Reaction score
0
I'll save you the trouble. During my phone call, discussing virtualization, the sangoma tech support guy mentioned that people could NOT seem to get this to work with ESX - things were not being handled correctly somehow.
 

Linetux

Guru
Joined
Oct 5, 2008
Messages
541
Reaction score
1
Hmmm.

I'll try my Linux and ESX kung-fu on this. I have a spare UT-50 in my office... somewhere...
 

kflorian

Member
Joined
Feb 18, 2010
Messages
76
Reaction score
4
Any reason to think that esxi 4.1 is "better" than any other vmware version. USB pass through only became available in esxi with 4.1. (I don't know about other esx versions)

I have a screen shot which clearly shows that centos is seeing the attached usb devices. I just don't have enough knowledge to go beyond following Sangoma's step-by-step instructions to diagnose myself. This really seems like it could work.

If you can't find the UT-50 I'll put mine in the mail to you for the experiment.

Ken
 

dswartz

Guru
Joined
Feb 17, 2009
Messages
1,056
Reaction score
0
According to the tech, the usb info does in fact pass thru, that isn't the problem. All the people they had try it could never actually get any clocking from it. And when I tried it with kvm passthru, it worked, but generated garbage for the timing.
 

kflorian

Member
Joined
Feb 18, 2010
Messages
76
Reaction score
4
I can confirm that USB performance on esxi 4.1 is faster than usb 1.1 and slower than usb 2.0 specifications.
 

kflorian

Member
Joined
Feb 18, 2010
Messages
76
Reaction score
4
Update:

Sangoma tech support worked with me to confirm that I'd compiled the UT 50 wanpipe voicetime drivers properly and that the timing device _appears_ to be running.

However, the dahdi_test numbers are not changed from before the installation of the UT 50...which is to say nowhere near the 99.975% which is what others' report as necessary for sufficient call control.

Running the UT 50 in a virtual environment is not supported by Sangoma (even though they were very gracious in trying to make it work).

Looks like it will not work at the present time.

Ken
 

unsichtbarre

Member
Joined
May 17, 2009
Messages
140
Reaction score
5
Here are some highly useful articles on timekeeping in VMware VMs

http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf

http://kb.vmware.com/selfservice/mi...nguage=en_US&cmd=displayKC&externalId=1006427

In addition, the mere installation of VMware Tools should help to stabilize the VMclock. I get results in the high 99.9's using ztdummy and have no trouble conferencing on a VM.

Always interested in improvement though.......

Code:
root@pbx:~ $ zttest
Opened pseudo zap interface, measuring accuracy...
99.918167% 99.994919% 99.925194% 99.997162% 99.985252% 99.918846% 99.990128%
99.913872% 99.988785% 99.913773% 99.986626% 99.986816% 99.914162% 99.987495% 99.916801%
99.986908% 99.989258% 99.919724% 99.991402% 99.918266% 99.988571% 99.916893% 99.989655%
99.986816% 99.915817% 99.985840% 99.914352% 99.987900% 99.916992% 99.985931% 99.982811%
99.909370% 99.984863% 99.914452% 99.991119% 99.918159% 99.978516% 99.998627% 99.920120%
99.987305% 99.916115% 99.988190% 99.917290% 99.987503% 99.987503%
--- Results after 45 passes ---
Best: 99.999 -- Worst: 99.909 -- Average: 99.958095, Difference: 99.971610
 

dswartz

Guru
Joined
Feb 17, 2009
Messages
1,056
Reaction score
0
Okay, here's where I am at. Since I was never able to get the UT51 working in a VM (kvm or pvm), I decided to swap things. The gateway/firewall is now virtual, and piaf has been moved to the atom 330 unit. I ran dahdi_test twice, once vanilla and once after installing the driver for the UT51 and restarting dahdi.

Before:
Best: 99.994 -- Worst: 99.618 -- Average: 99.959939, Difference: 99.998103


After:
Best: 99.993 -- Worst: 99.955 -- Average: 99.990219, Difference: 99.991200
 

unsichtbarre

Member
Joined
May 17, 2009
Messages
140
Reaction score
5
I was on a call the other day on my ESX virtualized PIAF and the call quality was less than I had come to expect. I know the consensus seems to be NOT to virtualize PIAF due to the lack of a configurable timing source, but for mt, a physical PIAF is not an option.

So I started looking around and noticed that my CPU Ready values were a bit high on the PIAF VM in a comparatively idle state. For those unfamiliar with CPU Ready, it is the counter that measures the amount of time a VM (or process) is ready and waiting for a CPU.

Anyway, high and/or fluctuating CPU Ready is not uncommon in an idle VM; it is mostly due to the VM oscillating between CPU's or cores on the ESX/ESXi and, in a system with available resources, CPU Ready will drop to 0 or near 0 when the CPU is taxed.

I began to wonder how to reduce my CPU Ready values at comparatively low utilization. The answer is in setting the Advanced CPU property of the VM "HT Sharing" to None.
The performance chart below demonstrates what happened to my CPU Ready before and after I turned HT Sharing off! The result was an immediate and perceptible improvement to call quality.
CPUReady.jpg


Here's what the actual setting looks like:
advancedcpu.jpg


--- Results after 101 passes ---
Best: 99.987 -- Worst: 99.925 -- Average: 99.953913, Difference: 99.991698
 

kflorian

Member
Joined
Feb 18, 2010
Messages
76
Reaction score
4
I have PIAF running tolerably well in a VM but I still have the experience of each speaker "stepping" on the others voice. The familiar "go ahead", "no, you go ahead" happens a fair bit during a 1 hour conversation.

Is conversation exchange smoothness improved with a hardware-based timing source?

I do not need conferencing ability and only a single line (one party on each side) is ever active.

Thanks,

Ken
 

luckman212

Guru
Joined
Jul 7, 2010
Messages
272
Reaction score
0
I experience this too (either as echo or a perceivable delay) using my Polycom IP335 from time to time. I don't use a jitter buffer. Any other tips for reducing latency or minimizing this effect? Would messing with Ptime affect this? I've worked to reduce as many bottlenecks as possible (25meg FIOS uplink, phone is on gigabit enet switch with VLAN tagged QoS, router prioritizing RTP traffic, etc. Can't seem to push this any further. I'm the only one using this PBX and I keep an eye on the loads so it's not a load issue (I wish it were- that would seem to be much easier to solve, just throw more horsepower at it)
 

kflorian

Member
Joined
Feb 18, 2010
Messages
76
Reaction score
4
I should note that I am using a Polycom IP335 as speaker phone.

I've done my own versions of the optimizations mentioned by luckman212.

I'll certainly acknowledge that the VM could be to blame except that generally the call is fine and workable. This is a refinement that would simply make it near-perfect.

Ken
 

luckman212

Guru
Joined
Jul 7, 2010
Messages
272
Reaction score
0
Hmm... so one common theme is "Polycom IP335" ... wonder if that's the key? What codec(s) are you using? How about VAD or echo cancellation on the endpoint itself via the phone's XML config? Done any tweaking there? How about software version on the phone? I've got BootROM 4.3.0.0246 + SIP.ld 3.3.1.0933 if that matters. I use G722 and G711u exclusively.
 

kflorian

Member
Joined
Feb 18, 2010
Messages
76
Reaction score
4
Brave new world for me...

Bootrom 3.2.3.0021
SIP.id 3.1.2.0392
(trying to learn how to update)

I think I am using only G722 but, again, still learning how/where to specify these things. I have a nearly pristine install of "purple" as it existed in late December. I set G722 at the extension level.

I've touched nothing else.
 

Gotenks

Member
Joined
Nov 19, 2009
Messages
63
Reaction score
0
I was on a call the other day on my ESX virtualized PIAF and the call quality was less than I had come to expect. I know the consensus seems to be NOT to virtualize PIAF due to the lack of a configurable timing source, but for mt, a physical PIAF is not an option.

So I started looking around and noticed that my CPU Ready values were a bit high on the PIAF VM in a comparatively idle state. For those unfamiliar with CPU Ready, it is the counter that measures the amount of time a VM (or process) is ready and waiting for a CPU.

Anyway, high and/or fluctuating CPU Ready is not uncommon in an idle VM; it is mostly due to the VM oscillating between CPU's or cores on the ESX/ESXi and, in a system with available resources, CPU Ready will drop to 0 or near 0 when the CPU is taxed.

I began to wonder how to reduce my CPU Ready values at comparatively low utilization. The answer is in setting the Advanced CPU property of the VM "HT Sharing" to None.
The performance chart below demonstrates what happened to my CPU Ready before and after I turned HT Sharing off! The result was an immediate and perceptible improvement to call quality.
CPUReady.jpg


Here's what the actual setting looks like:
advancedcpu.jpg


--- Results after 101 passes ---
Best: 99.987 -- Worst: 99.925 -- Average: 99.953913, Difference: 99.991698

I am installing PiaF to an ESXi host and have now also made this change. Thanks a lot for your insight!
 

nievz

New Member
Joined
Dec 2, 2011
Messages
28
Reaction score
1
UT50 Underperforming

Hi Guys, do you have any idea why i'm getting low score using the UT50?

Here's the output with it installed:
# dahdi_test
Opened pseudo dahdi interface, measuring accuracy...
99.918% 99.984% 99.984% 99.984% 99.984% 99.984% 99.984% 99.985%
99.985% 99.984% 99.985% 99.984% 99.984% 99.984% 99.918% 99.985%
99.984% 99.984% 99.984% 99.985% 99.984% 99.984% 99.984% 99.984%
99.984% 99.984% 99.984% 99.984% 99.984% 99.918% 99.984% 99.984%
99.984% 99.984% 99.984% 99.984% 99.984% 99.984% 99.984% 99.984%
99.984% 99.984% 99.984% 99.918% 99.984% 99.984% 99.984% 99.984%
99.984% 99.984% 99.984% 99.984% 99.984% 99.984% 99.984% 99.984%
99.984% 99.918% 99.985% 99.984% 99.985% 99.985% 99.984% 99.985%
99.984% 99.984% 99.984% 99.984% 99.984% 99.984% 99.984% 99.918%
99.984% 99.984% 99.984% 99.984% 99.984% 99.984% 99.984% 99.984%
99.984% 99.984% 99.984% 99.984% 99.985% 99.984% 99.918% 99.984%
99.984% 99.984% 99.984% 99.984% 99.984% 99.984% 99.984% 99.985%
99.985% 99.984% 99.985% 99.985% 99.918% 99.985% 99.984% 99.985%
99.984% 99.985% 99.984% 99.984% 99.984% 99.984% 99.984% 99.984%
99.984% 99.984% 99.918% 99.984% 99.984% 99.984% 99.984% 99.984%
99.984% 99.984% 99.984% 99.984% 99.984% 99.984% 99.984% 99.984%
99.984% 99.918% 99.984% 99.985% 99.984% 99.984% 99.984% 99.984%
99.984% 99.984% 99.985% 99.984% 99.985% 99.984% 99.985% 99.918%
99.984% 99.984% 99.984% 99.985% 99.984% 99.984% 99.984% 99.984%
99.985% 99.984% 99.984% 99.984% 99.984% 99.918% 99.984% 99.985%
99.983% 99.984% 99.984% 99.984% 99.984% 99.984% 99.984% 99.984%
99.984% 99.984% 99.984% 99.918% 99.984% 99.984% 99.984% 99.984%
99.984% 99.984% 99.984% 99.985% 99.984% 99.985% 99.984% 99.984%
99.984% 99.984% 99.918% 99.985% 99.984% 99.985% 99.984% 99.984%
99.984% 99.984% 99.984% 99.984% 99.984% 99.984% 99.984% 99.984%
99.918% 99.984% 99.984% 99.984% 99.984% 99.985% 99.984% 99.984%
99.984% 99.984% 99.984% 99.984% 99.984% 99.984% 99.918% 99.984%
99.984% 99.984% 99.985% 99.985% 99.984% 99.984% 99.984% 99.984%
99.984% 99.984% 99.984% 99.984% 99.984% 99.918% 99.984% 99.985%
99.984% 99.984% 99.984% 99.984% 99.984% 99.984% 99.984% 99.984%
99.984% 99.984% 99.984% 99.918% 99.984% 99.984% 99.985% 99.984%
99.984% 99.984% 99.984% 99.985% 99.984% 99.984% 99.985% 99.984%
99.984% 99.918% 99.984% 99.984% 99.984% 99.984% 99.984% 99.984%
99.984% 99.984% 99.984% 99.984% 99.984% 99.984% 99.984% 99.918%

--- Results after 27530 passes ---
Best: 99.991 -- Worst: 51.533 -- Average: 99.977927, Difference: 99.989438

Here's without:
# dahdi_test
Opened pseudo dahdi interface, measuring accuracy...
99.994% 99.999% 99.908% 99.977% 99.992% 99.995% 99.995% 99.909%
99.602% 99.995% 99.994% 99.994% 99.993% 99.994% 99.993% 99.994%
99.994% 99.615% 99.979% 99.994% 99.605% 99.908% 99.993% 99.994%
99.989% 99.999% 99.908% 99.993% 99.994% 99.992% 99.995% 99.908%
99.994% 99.994% 99.994% 99.994% 99.908% 99.992% 99.996% 99.993%
99.994% 99.995% 99.994% 99.994% 99.993% 99.908% 99.990% 99.996%
99.995% 99.993% 99.995% 99.994% 99.994% 99.994% 99.993% 99.908%
99.995% 99.994% 99.979% 99.994% 99.907% 99.994% 99.995% 99.979%
99.991% 99.994% 99.995% 99.992% 99.996% 99.909% 99.994% 99.994%
99.994% 99.979% 99.895% 99.995% 99.995% 99.994% 99.975% 99.891%
99.605% 99.992% 99.995% 99.907% 99.994% 99.994% 99.995% 99.992%
99.907% 99.994% 99.994% 99.994% 99.992% 99.907% 99.993% 99.994%
99.994% 99.994% 99.923% 99.993% 99.995% 99.995% 99.994% 99.923%
99.994% 99.995% 99.995% 99.597% 100.000% 99.993% 99.994% 99.995%
99.912% 99.998% 99.993% 99.994% 99.995% 99.910% 99.995% 99.994%
99.994% 99.995% 99.910% 99.996% 99.993% 99.994% 99.995% 99.992%
99.996% 99.993% 99.994% 99.995% 99.992% 99.996% 99.992% 99.992%
99.997% 99.992% 99.996% 99.993% 99.994% 99.907% 99.992% 99.996%
99.993% 99.994% 99.908% 99.992% 99.995% 99.993% 99.908% 99.995%
99.992% 99.996% 99.992% 99.995% 99.994% 99.992% 99.996% 99.993%
99.908% 99.995%
--- Results after 162 passes ---
Best: 100.000 -- Worst: 99.597 -- Average: 99.968747, Difference: 99.998801
 

Members online

No members online now.

Forum statistics

Threads
25,781
Messages
167,507
Members
19,201
Latest member
troutpocket
Get 3CX - Absolutely Free!

Link up your team and customers Phone System Live Chat Video Conferencing

Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.

3CX
A 3CX Account with that email already exists. You will be redirected to the Customer Portal to sign in or reset your password if you've forgotten it.
Top