[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-06 15:52 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...
====================================================================== 

---------------------------------------------------------------------- 
 (0101320) madrouter (reporter) - 2009-03-06 15:52
 http://bugs.digium.com/view.php?id=13205#c101320 
---------------------------------------------------------------------- 
I believe the way the XPP driver works is to have an adjustable oscillator
in the hardware.  The software keeps track of when the DAHDI clock ticks
(via the sync_tick callback) and when the hardware ticks and compares the
rate of the two.  If the hardware is ticking faster than DAHDI it commands
the hardware to slow down and if it's ticking faster it commands the
hardware to slow down.

The problem with just masking off the interrupt for cards that aren't
master is that almost certainly their local oscillators will be running at
a different speed to the DAHDI clock, so you're going to get slips/skips. 
If the current hardware doesn't have an adjustable oscillator then there's
no way of really dealing with the problem.

With regard to putting dahdi_dummy into dahdi-base, be careful that you
don't screw things up for people who know what they're doing for the sake
of newbies who can't RTFM.  An example of where letting dahdi figure things
out "automatically" is bad would be a test lab like the one I have set up. 
Two machines are configured identically with only dahdi_dynamic_eth spans. 
However - one of the machines needs to actually provide a real clock, so I
load dahdi_dummy and clock the first machine from that.  If dahdi tries to
be clever and figure things out the behaviour would be undefined. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-06 15:52 madrouter      Note Added: 0101320                          
======================================================================