Hello! I had posted a question a few months ago about running FreePBX on Windows Server 2012 R2 Hyper-V with 200 phones and 20 concurrent calls (see post Clocking/Timing: To Virtualize or Not to Virtualize). The response that I got was that it worked well for several hundred phones and 50 simultaneous calls as a VM in Hyper-V.
But now that I’m actually setting up a test FreePBX Server (Asterisk 13/FreePBX 14 [SNG7-FPBX-64bit-1904-2.iso] on Windows Server 2012 R2) I am seeing averages of 99.91% through 99.96% with 4 vCPU’s and 8GB of RAM when running dahdi_test. This is with 8GB RAM, 4 vCPU’s, and a reasonably fast disk sub-system. I didn’t make any changes to FreePBX/Asterisk - just used the default install. I also tried changing the Hyper-V Virtual Machine Reserve on the vCPU’s to 100% without success.
Does anyone have any suggestions on how to get the dahdi_test up to the recommended 99.97% average on a virtualized Hyper-V VM? I’d really appreciate any insight!
Thanks! Dave
Are you using DAHDI hardware in your virtualized server?
In the original thread, @Dickson (IIRC) was talking about a straight SIP installation. Adding DAHDI hardware changes the performance envelope of the underlying server considerably.
Wow, that’s interesting. Maybe I am thinking about this all wrong.
The plan will be to have a SIP trunk, although that isn’t configured yet. I just assumed (yes, assumed) that running a dahdi_test would show me the accuracy of the clocking/timing whether I had any dahdi hardware or not. I figured that it would use the internal Asterisk clock since there was no PRI hardware.
Am I incorrect in this assumption that I can still measure the clocking/timing with dahdi_test without dahdi hardware? And if I can’t use dahdi_test, how can I check the accuracy of the clocking/timing without running dahdi_test?
Thanks so much!
You can measure it, but it’s a meaningless metric if you aren’t going to be using DAHDI hardware, and adding virtualization on top of the IRQ interference that the DAHDI hardware tickles is the point of the exercise. It’s isn’t that measuring it without the hardware is possible or not - it’s like measuring your kids using “hands” because that’s how you measure a horse.
I don’t get why you think that DAHDI sync line clocking is going to be important on a system without DAHDI.
Ok, so if dahdi_test without dahdi hardware on a VM is meaningless, is there any way to determine the accuracy of the clocking for a VM without Dahdi hardware? I used dahdi_test in the past (with physical machines and Sangoma PRI cards) to make sure that the asterisk was “running well” and could handle a PRI’s worth of concurrent calls. Is there any way to tell that a VM has the proper clocking/timing to make sure that MoH, conference bridges, voicemail prompts, etc. all will sound good?
It isn’t the accuracy of the clock, it’s the available bandwidth in all of your system components, and that’s going to be hard to do.
As far as programs that can manage all of that, not that I’m aware of. There are lots of folks here (including Sangoma) that have set up VMs that might have some insight for you, but as far as I can tell, the vagaries of the nature of SIP and Asterisk really defy benchmarking ahead of time.
There are a couple of load simulators out there that can simulate a couple hundred calls - the original thread (IIRC) even had a pointer or two to them. Remember also that there are lots of things you can do to a perfectly tuned system to screw it over, including having to do stuff like transcoding audio on the fly (in your conferences or using a live audio stream, for example) that no one really thinks about when they’re designing their systems.
While the specifics of their server config is “close hold”, Sangoma has talked (@tm1000 I think) in general terms about how they set up their VMs to maximize the performance on those.
You are looking for network performance over all else
Thanks, dicko! Yes, these are best practices that I’m aware of. I wasn’t sure if there were specific Asterisk-related settings to change (either at the Hyper-V level or at the Linux/Asterisk level). I certainly appreciate your input!
dave
No, just that the defer any other choices to the network and the choice of network interfaces
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.