vicidial.org

Hi,

I have been running Asterisk and VICIDIAL for a week or so now with pretty much no problems overall. I know that the configuration I'm using with ztdummy instead of a hardware timer isn't ideal; however, the server is located ~500 miles from where I work and I don't have physical access to it (it will be a nightmare if not impossible to install the card) so I am looking for some feedback on the current performance.

Standard outbound calls from Asterisk are perfect, outbound calls from VICIDIAL using Meetme conferences are of good quality, conference calls with multiple people (E.g. when calls are transferred externally using VICIDIAL) exhibit delays which increase with time throughout the conversations.

I have included below the output from zttest with the following server setup. Can anyone provide similar output for their servers when operating with hardware timers and ztdummy and comment on how they and their staff find the various experiences mentioned above?

Regards,

Henry

Asterisk: asterisk-1.2.14
VICIDIAL/Astguiclient: 2.0.2 (VERSION: 2.0.73 BUILD: 61129-1028 - FROM GUI)
Zaptel: zaptel-1.2.12
Libpri:libpri-1.2.4
Kernel: 2.6.9-42.0.10.ELsmp

Code: Select all

[root@srv073 zaptel-1.2.12]# ./zttest -v
Opened pseudo zap interface, measuring accuracy...

8192 samples in 8292 sample intervals 98.779297%
8192 samples in 8231 sample intervals 99.523926%
8192 samples in 8245 sample intervals 99.353027%
8192 samples in 8223 sample intervals 99.621582%
8192 samples in 8191 sample intervals 99.987793%
8192 samples in 8197 sample intervals 99.938965%
8192 samples in 8190 sample intervals 99.975586%
8192 samples in 8186 sample intervals 99.926758%
8192 samples in 8334 sample intervals 98.266602%
8192 samples in 8406 sample intervals 97.387695%
8192 samples in 8285 sample intervals 98.864746%
8192 samples in 8213 sample intervals 99.743652%
8192 samples in 8182 sample intervals 99.877930%
8192 samples in 8197 sample intervals 99.938965%
8192 samples in 8199 sample intervals 99.914551%
8192 samples in 8190 sample intervals 99.975586%
8192 samples in 8199 sample intervals 99.914551%
8192 samples in 8189 sample intervals 99.963379%
8192 samples in 8187 sample intervals 99.938965%
8192 samples in 8302 sample intervals 98.657227%
8192 samples in 8262 sample intervals 99.145508%
8192 samples in 8246 sample intervals 99.340820%
8192 samples in 8213 sample intervals 99.743652%
8192 samples in 8264 sample intervals 99.121094%
8192 samples in 8285 sample intervals 98.864746%
8192 samples in 8191 sample intervals 99.987793%
8192 samples in 8197 sample intervals 99.938965%
8192 samples in 8199 sample intervals 99.914551%
8192 samples in 8189 sample intervals 99.963379%
8192 samples in 8187 sample intervals 99.938965%
8192 samples in 8278 sample intervals 98.950195%
8192 samples in 8301 sample intervals 98.669434%
8192 samples in 8318 sample intervals 98.461914%
8192 samples in 8205 sample intervals 99.841309%
8192 samples in 8207 sample intervals 99.816895%
8192 samples in 8214 sample intervals 99.731445%
8192 samples in 8198 sample intervals 99.926758%
8192 samples in 8198 sample intervals 99.926758%
8192 samples in 8198 sample intervals 99.926758%
--- Results after 39 passes ---
Best: 99.987793 -- Worst: 97.387695 -- Average: 99.506711


I think it should be the kernel version. I am sorry I am not able to provide you the link now , as I can't find it again. I remember there is this progressively worsening in meetme conferences for upto a certain version of 2.6 kernels also with ztdummy, not just 2.4.x. It was reported as a bug and resolved by upgrading the kernel. I am again sorry not able to provide correct info on the kernel version too.

I am sure someone here can show the zttests for earlier and later kernel versions. Hope it helps any.

regards

devafree

I've seen some posts regarding an upgrade to kernel version 2.6.13 which apparently offers some improvements but I can't find any definitive information regarding the tests. If anyone else can provide them then I'd really appreciate the information.

I will look into upgrading the kernel but the server is installed on VM Ware so I don't want to upgrade it to a version which is not compatible.

The VM Ware installation might also cause other issues since it's not installed directly onto the "bare metal" of the machine - has anyone else operated asterisk in this environment?

I cannot find the exact posting, but a few months ago someone on the Asterisk dev mailing list did a full set of zttest results using several different kernels and determined that using a 2.6.13 kernel or higher with the kernel timer set to 1000Hz was the best that you could do with ztdummy. Much better than earlier 2.6 kernels including 2.4 and using 1000Hz is better than using 250 or 100.

Is this the link you guys are talking about?

http://lists.digium.com/pipermail/asterisk-dev/2005-October/016218.html

and here

http://www.voip-info.org/wiki/index.php?page=Asterisk+timer+ztdummy

It discusses using USE_RTC for better ztdummy timing accuracy. There are patches out for this but 2.6.13 comes with it built in.

-Art

The post I'm referring to happened more recently, but it has basically the same information in it.

Having spent some more time researching, testing and generally messing with Zaptel I have some more information which people might find interesting.

Due to the problems with the location of my main servers I setup a test machine in my house to experiment with. The results are as follows:

The first machine is a powerful server located in a data centre in London running CentOS 4.5 on VM Ware (http://www.vmware.com/). This software allows system administrators to run multiple OSes on the same physical machine by abstracting away from the hardware. In hindsight it was obvious that this would cause timing problems and during the tests I have seen the % accuracy vary wildly either side of the 8192 result to achieve 100%. I think the moral of the story is never to run Asterisk on a VMware machine!

Code: Select all

Kernel 2.6.9-42 (on vmware using ztdummy)
--- Results after 89 passes ---
Best: 100.000000 -- Worst: 96.545410 -- Average: 99.348775
--- Results after 821 passes ---
Best: 100.000000 -- Worst: 94.055176 -- Average: 99.232871


This is an old machine I have in my house which I have experimented with. The default CentOS installation had a 2.6.9 kernel and actually showed some promising results using ztdummy.

Code: Select all

Kernel 2.6.9-xx (on bare metal using ztdummy)
--- Results after 146 passes ---
Best: 99.987793 -- Worst: 99.914551 -- Average: 99.975405


I compiled a new kernel from kernel.org which should have the more recent settings and set the timer to 1000hz. This didn't have a huge effect but if anything appeared to reduce performance. Though it could be that I have screwed up some part of the kernel compile process since I've never tried it before.

Code: Select all

Kernel 2.6.17-11 (on bare metal using ztdummy)
--- Results after 38 passes ---
Best: 99.963379 -- Worst: 99.938965 -- Average: 99.952778


Using the new kernel I also bought an X100P card to test. This improved the accuracy to the highest level so far, but only a marginal improvement over using ztdummy on kernel version 2.6.9. However, the results were more stable never varying much from the 99.98 mark where they fluctuated more on other tests.

Code: Select all

Kernel 2.6.17-11 (on bare metal with the X100P card)
--- Results after 1452 passes ---
Best: 100.000000 -- Worst: 99.951172 -- Average: 99.984106


Hope this helps someone else avoid installing Asterisk on a vmware machine!

Henry

Thanks for the info!

Yes, using virtualization is not good for Asterisk, or any other real-time application.

A hardware timer is always best, especially on high-load systems.