Summary:	ASTERISK-04086: zttool reports incorrect clocking
Reporter:	damin (damin)	Labels:
Date Opened:	2005-05-05 16:51:08	Date Closed:	2005-09-28 22:46:49
Priority:	Trivial	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) zaptel.conf.sample-patch.txt
Description:	Using zaptel-stable with a "span=1,1,0,esf,b8z2" line in zaptel.conf, zttool always reports "Internally clocked". ****** ADDITIONAL INFORMATION ****** The offending code?        if (s[span].syncsrc > 0)                strcpy(tmp, s[s[span].syncsrc].desc);        else                strcpy(tmp, "Internally clocked");        newtTextboxSetText(syncsrc, tmp);
Comments:	By: damin (damin) 2005-05-05 16:55:55 As a followup to this, the zaptel.conf.sample file does not clearly explain "Generated" or "Recovered" timing instead referencing "Primary" and "Secondary" timing sources. As I understand it, the timing can either be Internal or External. If it is recovered Externally from the line, then each span can have a priority and can act as a secondary timing source should the Primary span go down. Can this be clarified? If the behavior is as I understand it, I'll post a modified patch for the zapte.conf.sample file that will correct this. Also, if someone wants to take a quick look at zttool and fix this, I would be happy. By: damin (damin) 2005-05-06 15:34:25 From akohlsmith-asterisk@benshaw.com Fri May  6 16:34:04 2005 Date: Fri, 6 May 2005 09:23:24 -0400 From: Andrew Kohlsmith <akohlsmith-asterisk@benshaw.com> Subject: Re: [Asterisk-Users] PRI timing problems: Fax & Voice On May 5, 2005 09:52 pm, Greg Boehnlein wrote: > This is very confusing. Most clocking language in the industry refers to > either "Internal" or "Recovered" clocking. Basically, the span can either > use it's own clock, or attempt to pull it from the line. clock = 0 means internal clock = 1 means recovered from this span clock = 2 means recovered from this span if the span with clock=1 is down etc. -A. By: ewieling (ewieling) 2005-05-11 08:17:29 From: support@digium.com Unfortunetely zttool reports it's timing source incorrectly the majority of the time.  It is a known bug.  Do not rely on zttool's output to determine it's timing/clock source. If you have your span specified as "span=1,1,0,esf,b8zs" in your zapata.conf, then your card is taking timing from the telco if the telco is providing timing.  Otherwise, the card will default to being internally clocked if the telco is not providing it. Regards, Chris Hozian By: damin (damin) 2005-05-12 11:30:53 Sure, it is a known bug, but why? At the very least the diagnostic tools that are released for Zaptel should work properly. I don't think that is too much to ask, do you? Attached, please find a patch that I feel clarifies the "clock" parameters for the zaptel.conf file. By: ewieling (ewieling) 2005-05-12 11:47:22 Oh, I agree.  I just wanted to put the message I got from Digium support regarding this, so you know what the "official" response I got was. By: Kevin P. Fleming (kpfleming) 2005-05-14 21:06:07 Unfortunately that patch is not quite right either, for a multiple-span card. It could lead people to believe the wrong behavior... I do agree, though, that the current documentation is lacking, and makes no sense to those of with telco experience who are used to 'internal' and 'external' clocking being the accepted terminology (or 'generated'/'recovered', take your pick). As I understand it, the cards work this way: All spans on the card use the same clock source for transmitting, at all times. The source can be either the on-board clock, or the receive clock recovered from one of the spans. The selection of which receive clock to use is controlled by the priority numbers. Can someone who knows the hardware better than I do comment on this? If this is correct, then we can clear up the documentation. However, this is _not_ traditional telco hardware behavior... and that may be where some of the confusion is coming from. In normal telco hardware, every span can be set to transmit using the internal clock or the clock recovered from its receive stream. It is not common at all for spans to be able to use another span's receive clock as its own transmit clock, and users may be expecting these clock control settings to be providing this sort of behavior, when they don't. As best I can tell, the quad-span card _cannot_ let every span free-run and use its receive clock as its own transmit clock, independent of the other spans. On a practical basis, this is not really an issue since in nearly every environment the clocks on spans from multiple providers will be in sync with each other anyway, and the equipment on the other end can handle an out-of-sync (but not different frequency) situation just fine. By: Kevin P. Fleming (kpfleming) 2005-05-14 21:06:42 Need some input from the person who knows the framer on the board :-) By: Mark Spencer (markster) 2005-05-15 19:01:55 The syncsrc should provide us with the span which is *currently* supplying the actual sync.  As far as I know it is known to work in *most* situations *except* supposedly when there is > 1 card in the machine, but this hasn't been labbed up for me so I don't know if it's a bug in zttool or in wct4xxp.c or similar.  If someone will lab it up, I'll be happy to look. By: Kevin P. Fleming (kpfleming) 2005-05-15 19:51:37 If I had the hardware I'd do it... but you are more likely to be able to get it set up there :-) By: Olle Johansson (oej) 2005-06-05 17:27:10 Any update from the lab team? /Housekeeping By: Tilghman Lesher (tilghman) 2005-07-26 23:13:02 Suspended pending a lab setup for testing By: Kevin P. Fleming (kpfleming) 2005-07-27 07:17:44 We need to leave this one open; I'll get it labbed up at Digium when I return from my trip next week, it's important that this get resolved for 1.2. By: Kevin P. Fleming (kpfleming) 2005-09-28 22:46:36 We are no longer able to duplicate this problem with CVS HEAD. If you can do so, please call tech support and ask for Matt O'Gorman so he can find out what your system configuration is.