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

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13205 
====================================================================== 
Reported By:                biohumanoid
Assigned To:                kpfleming
====================================================================== 
Project:                    DAHDI-linux
Issue ID:                   13205
Category:                   dahdi (the module)
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
====================================================================== 
Date Submitted:             2008-07-31 00:11 CDT
Last Modified:              2009-03-11 02:14 CDT
====================================================================== 
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...
====================================================================== 

---------------------------------------------------------------------- 
 (0101513) biohumanoid (reporter) - 2009-03-11 02:14
 http://bugs.digium.com/view.php?id=13205#c101513 
---------------------------------------------------------------------- 
tzafrir> * What about analog cards that have no "timing" defined?
They do have an internal oscillator, so they can be used as a timing
source.

tzafrir>* How do you deliver the information that certain spans should
have a priority that is lower than a "local device" (that is: they can
provide no timing whatsoever)?
Any device driver is interrupt driven. Interrupts are produced using
internal oscillator (Analog) or from external oscillator{from line}
(PRI/BRI/...).

KNR>I am testing the patch provided from madrouter and it works fine
Yes, syncprio must be used for choosing a master for DAHDI.
But you have to fix all DAHDI-based device driver (because only god knows
how they are using syncprio :-) )

KNK> With weight 0 for PRI, weight 1 for BRI and weight 5 for eth
wow, wow....
1. You should do priority suffix in asterisk gui, freepbx, any script.
2. The users are not always dump. They want flexibility, but you are going
to fix it in the kernel...

madrouter>I don't think any of the other hardware manufacturers have any
way of letting DAHDI clock the card rather than the other way around.
Our hardware do (one of them
http://www.parabel-labs.com/products/asteroid/ ). 
Our hardware can tune an internal oscillator using timing from dahdi. So
no slips/skips...

That's why I'm interrested to have correct master selection.
DAHDI can not even tell the user, that there are slips/skips !!! No
slips/skips counters exported at all !!! 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-11 02:14 biohumanoid    Note Added: 0101513                          
======================================================================