Does x100p act as a good timing source?

thanks kerry. thats what i was planning on doing. i don't intend on using it for PSTN as I have no need for a PSTN line currently and also the bad history of the x100p performance.

My zttest scores is:
--- Results after 28 passes ---
Best: 99.962 -- Worst: 98.544 -- Average: 99.856463, Difference: 100.053128
[server2.ABPNI.local ~]#

and I'm experiencing some jitter overall. do you hink the x100p will fix this? Cheers

well the jitters occur accross the board. everywhere. they are random, and sometimes they don't happen at all and when they do, it may only happen once in an average length voicemail call. sometimes I can't even use a trunk to call out coz its so jittery (however this is very rare).

thoughts?

Cheers

nail on the head kerry!

So bottom line:

Timeing is used for playback,conferancing and transcoding?

Otherwise its ok?

Come to mention it, thats when the problems occur - either during transcoding or playback.

BTW, how do my test scroes fair compared with others?

Cheers

hmmm.

your test box 2 may have just made my heart sink. My box is:
--- Results after 32 passes ---
Best: 99.963 -- Worst: 99.865 -- Average: 99.951444, Difference: 100.006753

does ur box 2 have any problems? do you think my "random" packet drops could just be due to the instability of my clock?

yea

in the past few minutes iv been obsessing with zttest and getting averages of like 99.94xx
so my timing is pretty bad!!

So you wreckon a crappy, x100p from ebay will fix this then? I've herd so many bad things about them

ok i went into BIOS and got excited over a setting that i had missed previously called "Enable multimedia Timer".

So i enabled it:

[server2.ABPNI.local ~]# zttest
Opened pseudo zap interface, measuring accuracy...
99.942680% 99.964645% 99.867096% 99.962601% 99.962402% 99.942192% 99.962402%
99.942192% 99.963470% 99.942284% 99.962402% 99.962402% 99.942184% 99.485550% 99.941605%
99.962402% 99.941895% 99.962402% 99.962303% 99.771584% 99.962494% 99.942192% 99.961815%
99.941795% 99.962891% 99.962402% 99.942284% 99.962402% 99.942284%
--- Results after 29 passes ---
Best: 99.965 -- Worst: 99.486 -- Average: 99.928526, Difference: 100.027583
[server2.ABPNI.local ~]#

if anything, my results have got worse lol

well ill let you know when the x100p arrives and we'll see if there is any change. if its not the timing then it must be the NIC

There is a tool called ztclock. Below my quote is an explanation from the author. This is the most insight I have gotten into Asterisk timing issues.

This test appears to be more accurate than zttest.

I have installed an Openvox card in the HP server that was giving me trouble and the voice prompts sound much better.

Scott

[/code]
ztclock - clock source accuracy test (3 passes)

Flushing input buffer...
Flush Complete.

Test is approximately 3 minutes. Please wait...

483328 samples in 60.410900 sec. (483288 sample intervals) 99.991722%
483328 samples in 60.410901 sec. (483288 sample intervals) 99.991722%
483328 samples in 60.410899 sec. (483288 sample intervals) 99.991722%

Estimate 8 frame slips every 12.083200 seconds.
-- snip --

Background:
During routine codec/dimensioning testing, I observed a strange, recurring cpu spike occuring appoximately every 12 seconds on a completely idle system with only the zaptel drivers loaded. I used 'vmstat 1' to monitor this. I was using the wcfxo driver (wildcard fxo) as a timing source. After switching to the ztdummy driver and using the usb controller as a clock source, I observed that the frequency of the CPU spikes changed to approximately every 5.5 seconds. Hmm... Also, as additional channels were added to the system, the CPU spikes increased in intensity (ie: from 15% utilization to 50% each spike).

Further research indicated that many folks using various flavors of FXO cards were experiencing similar observations as well as problems with data applications such as spandsp. Some of them are observing similar CPU spikes using the TDM400P hardware. I tried to use zttest to put a finger on the problem, but could not seem to get the resulting math to work out. I believe that ztclock may provide some insight into what is happening with those spikes. The test attempts to first determine the accuracy of your clock source compared to the results that could be expected from a true 8khz clock source. Once this is accomplished, it uses the results of the third pass in an attempt to calculate the time frequency that you should expect to see 8 frame slips. I selected 8 frame slips for the calculation instead of 1 because it appears that the zaptel driver moves 8 samples / interrupt / channel. It also appears that the data is clocked across the PCI bus in a similar manner. My calculated frame slip result seems to correspond directly with the frequency of the CPU spikes that I observed, suggesting a possible relationship.

I'd like to hear from anyone who may be tracking this or similar issues. I'd also like to hear some feedback on the ztclock program itself in terms of how it seems to work against various clock sources that you may have available.
[/code]

hey. im just waiting on a PCI express sangoma card from Voipon.

I did receive a PCI one from a guy on ebay but I needed PCI express...

For wot it's worth, the PCI one did help timing a lot. still got a few stutters though however zttest gave MUCH better results

Glad the timing worked for you.

You have to download the source. It will then be in usr/src, don't hold me to this.

Scott

I have been testing this today to see if a cheapie X100P clone would do the trick for timing, and I've got to say it really doesn't do well in this dept. On a brand new HP server, with nothing but ztdummy loaded (service zaptel stop and then modprobe ztdummy) I get this on a 50 pass zttest run:

--- Results after 49 passes ---
Best: 99.975 -- Worst: 99.929 -- Average: 99.955935, Difference: 99.988190

after I load up the wildcard fxo driver: (service zaptel start) on a 50 pass zttest run:

--- Results after 49 passes ---
Best: 99.974 -- Worst: 99.878 -- Average: 99.953831, Difference: 99.990436

so while these wildcard x100p's are fun to tinker with, they aren't serious contenders on any front.

So let me ask this question as I am quite the Newbie.

Once I get the Sangoma T1 card with echo canc, this will provide an acurate timing source?

Am I understanding this correctly?

Thanks

Thanks for the reply Skykingoh, as usual a wealth of information.

Echo cancel is a must? Even on T1 lines?

Right now the customer has a BBS Telecom "Vendor Named" system with 8 8 port cards and a T1 line that this will be replacing, so about 40+ phones plus fax lines.

The actual system is a Plexus PBX system that is rapidly failing them, 2 8 port cards are randomly changing port assignment about 1-2 times per month, the T1 will simpy go bye bye and the phone system throws a fast busy on dials, the HD is making noise, and the big thing is support, we could only find one vendor for this system and he charges even for simple questions. I have never seem a Plexus system before, I have used Panasonic, Nortel etc, this system is clunky and hard to use and the customer is ready for a change, I just want to make sure it is the right system for them.

I spoke with the receptionist, and even though they have a T1 line she has at most had to juggle 4-5 incoming calls at a time. They are in love with thier DID numbers and bypass reception by giving customers thier DID numbers so this will be a big issue with the new system.

Thanks again to everyone for the hand holding :)