[asterisk-bugs] [DAHDI-linux 0013205]: [patch] bad master selection

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=13205 
====================================================================== 
Reported By:                biohumanoid
Assigned To:                sruffell
====================================================================== 
Project:                    DAHDI-linux
Issue ID:                   13205
Category:                   dahdi (the module)
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
JIRA:                        
Reviewboard Link:            
====================================================================== 
Date Submitted:             2008-07-31 00:11 CDT
Last Modified:              2011-02-16 05:16 CST
====================================================================== 
Summary:                    [patch] bad master selection
Description: 
Current dahdi master handling work in the following way:
The first SPAN become a master
If a new registered !!! SPAN is preferred , it is the new master
If a span is unregistered - the new master is the first available span
If master SPAN is in alarm state - the new master is the first non in
alarm state SPAN

So
1. dahdi-dummy once loaded will be the master forever.
2. even not-running SPAN can be a master
3. master implementation is ugly...
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0013206 [patch] ztdynamic double buffering on r...
====================================================================== 

---------------------------------------------------------------------- 
 (0132015) biohumanoid (reporter) - 2011-02-16 05:16
 https://issues.asterisk.org/view.php?id=13205#c132015 
---------------------------------------------------------------------- 
sruffell: You bring up some good points, but instead of addressing them
(specifically about the details in the code) perhaps we should just focus
only on flow charting how the master span and timing sync for the different
potential clock domains should be selected? 

reasonable.

sruffell: There's the global master, the sync source on multiport cards,
and cards that can potentially share timing via cables. Am I missing any
others?

Even more simple:
1. Global master - Master for the whole DAHDI, and, should be the master
for all cards/spans.
2. SPANS which can provide timing.
One of this SPAN's must became a sync "Global master".
3. SPANS which can't provide timing.

I think, we shouldn't differ cards with a timing cable, cards without
timing cable, dynamic span devices.
Any 2 cards can have "external timing cable" - we can connect card1:line4
with card2:line1, and
span=1,1,0, span=2,0,0, span=3,0,0, span=4,0,0
span=5,2,0, span=6,0,0, span=7,0,0, span=8,0,0
So, SPAN1 will receive sync from TELCO, SPAN5 will receive sync from
SPAN4(from TELCO).
Card1 & card2 will be in sync, but DAHDI will know nothing about it...
But the user will.

Lets examine sync source on multiport cards.
span=1,1,0, span=2,0,0, span=3,0,0, span=4,0,0 #card1
span=5,2,0, span=6,0,0, span=7,0,0, span=8,0,0 #card2
card1 will use port1 (SPAN1) a sync source for the whole card. It's good.
card2 will use port1 (SPAN5) a sync source for the while card.
SPAN1 will be the "Global Master", and all cards will be in sync with it. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-02-16 05:16 biohumanoid    Note Added: 0132015                          
======================================================================