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

[Michael Walton (JIRA)]

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

Michael Walton commented on DAHLIN-329:
---------------------------------------

Hi Pavel

Thanks for the comments. I have a question, you say "Neither patched, nor original dahdi-base will not let TDMoE device became "(MASTER)" SPAN". We also use this on our hardware, we have many installations where DAHDI master timing is derived from our TDMoE device. I have not done too much testing with 2.7.0.1, we use 2.4.1 in production. My question: why can the TDMoE device not become master span?

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.

msgbuf2 is used to temporarily store the FIFO contents from kfifo_out in dahdi_process_rxfifo(), before copying into the channel readchunk buffers. We could share msgbuf with sendmessage I guess?

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