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

[Pavel Selivanov (JIRA)]

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

Pavel Selivanov edited comment on DAHLIN-329 at 11/7/13 12:51 PM:
------------------------------------------------------------------

> 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).
TDMoE device can became a MASTER SPAN. dahdi_dummy cannot.

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

                
      was (Author: biohumanoid):
    > 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-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