[asterisk-bugs] [JIRA] (DAHLIN-329) Support multiple dynamic spans with FIFO

Pavel Selivanov (JIRA) noreply at issues.asterisk.org
Thu Nov 7 11:30:03 CST 2013


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

Pavel Selivanov commented on DAHLIN-329:
----------------------------------------

> Neither patched, nor original dahdi-base will not let TDMoE device became "(MASTER)" SPAN"
Oops, sorry, I read can_provide_timing instead of cannot_provide_timing (zero by default).

>Also, the "DAHDI will have an awful timing source (in the worst case, 999ms, so, 1Hz instead of 1000Hz)", I don't agree. This is only for a short time to allow switching back to the core timer when no more masters are available. Won't happen in normal circumstances.
Let's imagine, you have a buggy hardware/switch/ethernet driver, or just wrong configuration (your device is configured as a slave to TDMoE, while dynamic configured with timing >=1).
It's real situations we had. We had 3com driver (grouping incomming packets 2 per 2), wrong configuration.
I'm not talking, original dahdi-base will deal it, just pointing one more bug for the community.
I'm just writing my opinion - the kernel driver should be as tiny as possible.
Mixing 2 timing implementations is not good.

>We could share msgbuf with sendmessage I guess?
I did it.

                
> Support multiple dynamic spans with FIFO
> ----------------------------------------
>
>                 Key: DAHLIN-329
>                 URL: https://issues.asterisk.org/jira/browse/DAHLIN-329
>             Project: DAHDI-Linux
>          Issue Type: Improvement
>      Security Level: None
>          Components: dahdi (the module), dahdi_dynamic
>    Affects Versions: 2.7.0
>         Environment: Kernel versions 2.6.24, 2.6.38 and 3.2.0 tested
>            Reporter: Michael Walton
>            Assignee: Russ Meyerriecks
>         Attachments: dahdi-base.c.patch, dahdi_dummy.c.patch, dahdi_dynamic.c.patch, dahdi_dynamic_eth.c.patch, dahdi-dynamic-multispan-fifo.patch, kernel.h.patch
>
>
> The dynamic span driver works for one span, but is unable to handle the phase differences caused by line and network jitter and clock drift in a multiple span situation. The introduction of a configurable receive FIFO,  proper master clock priority switching and slip/skip processing solves this problem. Additionally, to support configurations where no telephony hardware is present, the highres timer from (defunct) dahdi_dummy is re-introduced into dahdi base to replace the core timer functionality (which is limited to 250Hz) with a true 1000Hz tick. As with the core timer, this is the fallback timing when no span provides master timing.
> Dynamic multispan introduces:
>  * Configurable fifo on incoming dynamic frames
>  * Master/slave dynamic spans with priority switching based on alarm status
>  * All transmit and receive processing is done in the dahdi_dynamic_run tasklet to ensure proper handling of jitter and phase differences
>  * Unreachable spans (RED alarm) switch to a poll mode to prevent network being flooded by 1ms frames that go nowhere
>  * Slip/skip statistics per span available on /proc/dahdi/dahdi_dynamic_stats
>  * High res timer added to dahdi-base to replace core timer with true 1ms tick timer
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the asterisk-bugs mailing list