[Asterisk-Dev] is zttest actually working ?

[Rich Adamson]

> I tried to look for it on google, lots of people think its not working
> as it should be, is there some consensus on this ?
> 
> I tried to have zttest run on a dozen asterisk servers, only the cheap
> as single cpu models have 100%. Every single dual cpu processor i tried,
> dual xeon and dual opteron  ( i tried 4) will almost always give
> 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793%.
> 
> - is the zttest approach a reliable way of checking the interrupt handling ?
> - shouldnt zttest return 99,987783 as the normal, and 100% as being bad ?

Don't know about consensus, but would guess those that have looked
at zaptel/zttest.c probably don't have sufficient zaptel background
to form a strong opinion (including myself).

I played around with changing the code to express the results in some
understandable form (instead of percentages) and found what I believe
were logic errors in the code. The one error that was noticable involved
rounding. (A number like 1.6 simply dropped the digits after the
decimal instead of truly rounding up/down, and the math suggest
the output should be carrying more significant digits.)

Instead of the percentage, I wanted to "see" the raw numbers as an
aid in discovering whether percentages <> 100% involved a missed
interrupt, inadequate data transfer, etc. In changing the code, it was
fairly apparent (from multiple responses to my OP), there wasn't
consensus as to whether the design objective was exactly 1,000 
interrupts per second or 1,024 interrupts per second. (That's kind
of where the effort stopped.)

Personal opinion is that results from zttest code other then 100%
is a problem, but the resolution within the code is insufficient to
accuarately gauge the root cause for the variations. In other words, 
it seems that a variance somewhere between 99.97 to 99.99 is some
sort of threshold, but there is insufficient output to even guess
at what might be lurking to cause such a variance.

My focus in that effort was an attempt to discover why Steve
Underwood's spandsp would not function correctly on a digium TDM
analog fxo interface. I should probably note that spandsp has far
more success on digium T1/E1 cards then it does on the TDM analog
card, but the output from zttest on those two cards really don't
point out why the differences. (Steve's past diagnostic efforts
with several user attempts to run spandsp with the TDM card have
consistently suggested the TDM card is missing chunks of data,
but none of us know why. Since spandsp is attempting to function as
an analog modem, any missing pcm data will obviously affect modem-type
results even though the same missing data will not have that much
of an impact on voice. I have personnally gone through every single
suggestion including shared interrupts, pci latency settings, no
other apps running on the system, changed kernels from v2.4 to 
v2.6, changed motherboards, swapping a TDM rev C card with a TDM
rev H card (most current), changed IDE drives, etc, etc. I even 
dropped back to testing with a single digium x100p and got the same 
basic results.)

Steve indicated that spandsp did in fact function correctly with
the TDM-analog card some time ago, and believes something has
changed in the zaptel or card drivers that has now impacted
missing data. But, zttest is not the tool to discover _why_ that
might be the case. Steve also took a stab at writing a small
utility to loop data through the TDM card, but didn't explain
the output from the utility, so we have no idea whether its output
indicates a problem or not. That was about a month ago and have
heard nothing since then on it.

So, bottom line... zttest _might_ indicate an issue under some
circumstances, but those circumstances seem to be those involving
operational statistics that are _way_ out of spec. For those systems 
that are not that far out of spec, zttest is of zero help.

Since I've swapped out just about everything possible on a test
system, I'm under the impression the problem is either on the card
(most likely the TigerJet pci chip), or, zaptel/driver issues that
have not yet been discovered.

I'd certainly like to get to the bottom of this (as do several other
users), but I don't have the zaptel / OS experience to be able to
diagnose the issues.

Rich