[asterisk-bugs] [JIRA] (DAHLIN-25) [patch] bad master selection

[Shaun Ruffell (JIRA)]

    [ https://issues.asterisk.org/jira/browse/DAHLIN-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201894#comment-201894 ] 

Shaun Ruffell commented on DAHLIN-25:
-------------------------------------

{quote}
There are still some troubles with locating true MASTER in DAHDI 2.6.1.
1. ::master not initialized (::master = NULL).
{quote}

This is not a problem because it's declared static.  Static global variables are by definition initialized to 0 or NULL.

{quote}
2. even span with alarm can become a master, if old_master == NULL.
{quote}

This is again not a problem with core timer. If there is only one span, we want that span to become the "master". If the span in alarm is not providing timing, the coretimer will kick in and tick the spans.

{quote}
3. Nobody call __dahdi_find_master_span in _dahdi_unassign_span.
_dahdi_unassign_span have own find_master loop. What for ?
{quote}

I agree with you here. It would be better to have unassign span call something like __dahdi_find_master_span.  Would need some tweaking though because it probably is the way it is to eliminate the window where master would unnecessarily be NULL when the master is unassigned. So probably need to change __dahdi_find_master_span() to require chan_lock to be held when call and not take that lock internally.

{quote}
4. dynamic spans still can not become a master span.
WHY ?
{quote}

Why do you say that? dynamic local spans are the only one that cannot be the master span, since those are the only spans that set cannot_provide_timing in struct dahdi_span. Local spans cannot become the master since they have no way to "tick" on their own unlike all other spans. Granted, I've not set this up in awhile but I'm surprised that you say this.

{quote}
5. dummy span can not become a master span (it's good to have a backup span with good 1ms ticks, provided by HPET).
WHY ?
{quote}

Because the dummy_span is a concept that is expired. If dynamic_eth spans need a 1ms timer running, it should set one up itself instead of relying on the sync_tick from the core_timer.  For the vast majority of DAHDI users, they don't need a 1ms tick to mix audio that typically comes in 20ms chunks. It just adds unnecessary overhead.
                
> [patch] bad master selection
> ----------------------------
>
>                 Key: DAHLIN-25
>                 URL: https://issues.asterisk.org/jira/browse/DAHLIN-25
>             Project: DAHDI-Linux
>          Issue Type: Bug
>          Components: dahdi (the module)
>            Reporter: Pavel Selivanov
>            Assignee: Russ Meyerriecks
>         Attachments: 0001-dahdi-wip-Fix-dynamic_loc-span-operation-with-DAHDI-.patch, 2013.01.17-dahdi-base.c.patch, dahdi-base.c.patch, dahdi-base.c.patch, dahdi-base.c_syncprio.patch, dahdi_dummy.c.patch, dahdi_dummy.c_syncprio.patch, dahdi_dynamic.c_syncprio.patch, zaptel-base.c.patch, ztdummy.c.patch
>
>
> 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...
> ****** ADDITIONAL INFORMATION ******
> Implemented: correct(symmetric) master arbitrage
> 1. trying preffered master SPAN
> 2. trying non-zero channel SPANS
> 3. trying zero-channel SPANS (ztdummy,...)
> thus:
> 1. dahdi-dynamic CAN be (and it works perfect) a master
> 2. at any time, we can tell/expect - who is the master
> 3. If (and only if) we have no master - dahdi-dummy will be our master

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira