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

[Pavel Selivanov (JIRA)]

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

Pavel Selivanov commented on DAHLIN-25:
---------------------------------------

{quote}
This is not a problem because it's declared static. Static global variables are by definition initialized to 0 or NULL.
{quote}
Yep, sorry.

{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}
Yes, DAHDI will roll using core timer ticks. But it will not be reflected in procfs.
cat /proc/dahdi/1 will display "(MASTER)", what is not truth.

{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}
dynamic will fail test_bit(DAHDI_FLAGBIT_RUNNING, &s->flags), as nobody set this flag !
It's fixed in patch for dynamic, probably I should write it there...
https://issues.asterisk.org/jira/browse/DAHLIN-26 .

{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.
{quote}
It theory - I would agree, but in practice some bad use-cases:

1. "static" span - from PSTN. dynamic span - to local PBX. PSTN - sync source for DAHDI, local PBX.
span=1,1,0,cas,hdb3,crc4
dynamic=eth,eth0/00:02:b3:35:43:9c,30,0
If span is in alarm - dynamic will be ticked by core_timer.
core timer will do 1000/HZ ticks (4 in my case) every HZ/1000 ms.
On first tick, dynamic will run tasklet.
ticks 2-4 will be lost, as tasklet will not even start.
It will be rejected with "if (likely(!taskletpending))"

2. "dynamic" span 1 - from PSTN. "dynamic" span 2- to local PBX. PSTN - sync source for DAHDI, local PBX.
dynamic=eth,eth0/00:02:b3:35:43:9c,30,1
dynamic=eth,eth0/00:02:b3:35:43:9d,30,0
If dynamic 1 will lost link (RED alarm), will burn - dynamic 2 will be ticked by core_timer.

So, it's good to have a backup sync source.
Moreover, patched __dahdi_find_master_span even more compact, than the original one (nobody loose nothing).

It's also possible to rework tasklet in dynamic (to run tasklet untill taskletsched != taskletrun, but deadlock protection).

Thank you for a dialog, I appreciate it.

                
> [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