zttest score running ztdummy

All installation and configuration problems and questions

Moderators: gerski, enjay, williamconley, Op3r, Staydog, gardo, mflorell, MJCoate, mcargile, Kumba, Michael_N

zttest score running ztdummy

Postby henry » Mon Mar 19, 2007 10:21 am

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
henry
 
Posts: 18
Joined: Mon Mar 12, 2007 5:08 am

Postby devafree » Mon Mar 19, 2007 2:50 pm

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
devafree
 
Posts: 180
Joined: Wed Sep 20, 2006 5:03 pm

Postby henry » Mon Mar 19, 2007 2:59 pm

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?
henry
 
Posts: 18
Joined: Mon Mar 12, 2007 5:08 am

Postby mflorell » Mon Mar 19, 2007 4:29 pm

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.
mflorell
Site Admin
 
Posts: 18334
Joined: Wed Jun 07, 2006 2:45 pm
Location: Florida

Postby enjay » Tue Mar 20, 2007 6:34 pm

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
enjay
 
Posts: 806
Joined: Mon Jun 19, 2006 12:40 pm
Location: Utah

Postby mflorell » Tue Mar 20, 2007 8:10 pm

The post I'm referring to happened more recently, but it has basically the same information in it.
mflorell
Site Admin
 
Posts: 18334
Joined: Wed Jun 07, 2006 2:45 pm
Location: Florida

Postby henry » Wed Mar 21, 2007 6:21 am

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
henry
 
Posts: 18
Joined: Mon Mar 12, 2007 5:08 am

Postby mflorell » Wed Mar 21, 2007 6:37 am

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.
mflorell
Site Admin
 
Posts: 18334
Joined: Wed Jun 07, 2006 2:45 pm
Location: Florida


Return to Support

Who is online

Users browsing this forum: Bing [Bot] and 57 guests