zaptel vs dadhi vs asterisk 1.8 what are your thoughts about

[bobbymc]

my personal goal is to virtualize asterisk which i know is a big no no. so far i found a small patch to ztdummy/dadhi_dummy that disabled RTC and "should" solve the timing issues in VMs. But since the vici group is working on making vicidial compatible with asterisk 1.8 wouldnt the timing issues be solved at that point? from what i heard asterisk 1.8 does not use dadhi for timing anymore and has its own build in timing source.

Any feedback is appreciated =)

[bobbymc]

the ultimate goal would be to pass a USB timing source from the host to the guest. For that im still working on creating a kernel module for citrix xen. if i ever succeed i will post here the source of the module

[williamconley]

The ultimate goal would be to utilize a non-physical timing source that was capable of hi-res timing inside a virtual system. OR a Conference solution that does not require hi-res timing but still capable of all the functionality (and speed) of meetme.

Until one of those goals is met, the likelihood of Virtual Vicidial being of any use is highly unlikely. Since USB is physical, the limitations are fairly heavy. Calling a Colo (or someone at Amazon?) at 3AM to "quick pop in a couple more USBs" so you can fire up a couple more servers is ... unlikely.

But if you are in need of help on your path, feel free to ask. I've seen several "very close" and several claims to success ... but I still don't see a Cloud version of Vicidial advertised anywhere.

[mcargile]

If you get digging into the posts on Asterisk 1.8 about using timing sources other than Dahdi, as soon as you have a problem the first thing they recommend doing is switching back to Dahdi. The POSIX timers are not as reliable as Dahdi timers. This is because they are still a software based timer built into the kernel. As with all things Virtual the Virtual Machine can still interrupt the execution of the Kernel pretty much whenever if feels like. This includes when one of these timers is ticking.

[bobbymc]

i would pay to have someone build a module of some sort to pass usb sticks from a xen host to multiple xen guests

[Acidshock]

Doesnt ProxMox have some ways of getting around this? I know they have some kernel hacks and you can also dedicate usb host hardware to vms. Maybe you get a 4:1 or 8:1 ratio but its still a hell of a lot better than a 1:1.

[bobbymc]

yea proxmox does.. im just not too familiar with it.. i love citrix forums and api so much its hard to move away =)

[Acidshock]

I dont know much of proxmox either but I have seen 500 server clusters virtualizing quite a lot of virtual machines and all scripted and deployed on demand so I know its doable. However I agree Citrix is really nice, and I really like all their products... they are just rather proud of them as far as the price tag lol

[bobbymc]

Kvm is the answer

[williamconley]

Actually, I'm not sure the problem for timing is related to the dahdi in the dialer as much as it is the hi-res timing in perl. Perhaps it is both. But I've had 150 meetme rooms active in a virtual server in AWS with dahdi running quite smoothly. The limitation of 150 was apparently in the meetme application, and not a timing issue per se. But the problem with a shared processor when using hi-res timing is (apparently) that all ticks in the nano-second clock are used. missing one will eventually cause a process to "not fire" and a call will go askew.

[bobbymc]

if im not wrong AWS sits ontop of a system like xen which shared CPUs, i wasnt aware that perl relines on hi-res timing and it would be nice if you could possibly point me out in which script it does make use of it, thx =)

About 150 being a max number, i never knew about there being a limiting factor. is this part of asterisk?

[williamconley]

perl does not rely on hi-res timing. vicidial scripts do! and they use perl hi-res timing to "get the job done".

just look for hi-res being activated in scripts in /usr/share/astguiclient (the home of many of the perl scripts) and in the agi-bin (several others!)

[bobbymc]

can you give me a code snippet of what code uses the timing? do you mean the date function used in perl?

[williamconley]

cd /usr/share/astguiclient
grep hires * -R -n

[bobbymc]

interesting!! im going to attempt to visualize asterisk in KVM / qmue soon. My goal is to take more advantage of the hardware. current issue is that when asterisk load goes over 50% wired issues start to happen with the perl scripts that require timing and things like transfers or other actions start to break. My goal is to possibly get 2 asterisk instances out of a box so i can utilize maybe 80% of the box instead of only 50%. is this idea flawd or even wroth testing out?

[williamconley]

always worth a try, i'd be interested to see if you can increase performance to 80%. that was the best description of the problem i've heard to date (50% utilization sounds about right, too).

[bobbymc]

something just dawned on me.. the issue with a asterisk server going over 50% is that the perl scritps run on that box start to suffer due to the lack of timing being avaliable to them. what if i was to host the perl scritps on a different box. wouldnt i be able to put more load on the asterisk boxes?

[williamconley]

Would be fun ... except the perl script in question issues commands to asterisk ... locally ... (remote proved to be unreliable ...)

[bobbymc]

You mean east manager send ? And what exactly was unreliable so I can watch those issues more closely ?

[williamconley]

anything and everything. if a tick is missed during hi-res timing and the script attempts to execute a specific item during that missed tick ... it fails. since that system controls call routing ... anything can happen. At least this is my summary/assertion of what happens. Based on my understanding of the scripts and observations of "what happens". Virtual server stability can be very helpful, but in the end any stress breaks down the system ... even in a non virtual server system when the ticks are missed.

[bobbymc]

Do you think its possible to send the system timing to an device like wanpipe_voicetime ?

[williamconley]

Sure, for voice generation. But hi-res perl timing is not related to voice generation, wanpipe, or even dahdi.

Find a new hi-res perl timing method and ... bob's your uncle. (assuming, of course, the new timing method is viable in a virtual environment)

[mcargile]

There are other problems with Virtual Machines other than the passing of the timing ticks. The most important is IO scaling. If you are already maxing out the IO subsystem without Virtualization your are not going to see any performance improvements by adding Virtualization on top of it. While asterisk / Vicidial are a fairly processor intensive applications they are also a very IO intensive one. The Virtualization host server only has a single system bus. It only has a single disk controller. These do not scale as you add more processing cores.

We do know of a company out of Germany that was able to successfully get Vicidial working in a Virtual environment using OpenVZ. After nine months of work they were able to get five Vicidial instances running on a massive box. Each one of those instances could handle maybe 4 agents. If they had more than that their instance would start to mess up. The cost for the hardware and development time could have easily paid for a blade center. Each blade handling up to 25 agents without problems. As far as I know said company has gone out of business.

I know you really want to be able to use Vicidial in a virtual environment, but seriously it has been tried multiple times before. Until server /chip manufactures start focusing on IO throughput you will not see any benefit from doing this.

[williamconley]

Pretty much the same reasoning behind "multiple small cost-effective" servers instead of "monster servers". There is still only ONE server and that means there is a bottleneck with front side bus which cannot be bypassed. Thus the advantage of the mutliple mini-servers is that each comes with another front side bus.

Of course, you can put in multiple drive controllers, which can greatly improve i/o throughput ... but not once you max your bus. Then the game is over.

And we, too, have observed multiple players in the virtual game ... and the Only useful results have been that of multi-tenants. If you can put 4 clients with 2 agents each (total 8 agents, 16 calls?) on a single Monster server .. and that monster server cost less than 4 mini-servers ... then you're doing well. But there is no guarantee that a virtual vici will hold more than one agent (stable) and that monster server could have easily held 25 agents before the virtual was invoked.

There are still those trying, though.