[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