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

Thu Nov 7 03:10:04 CST 2013

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

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

Timing patch in dahdi-base.c.

A little theory needed, to understand, how it works and how it should work.
It's not just a theory, it's a practice, as we user TDMoE in our hardware.

== Original DAHDI provides timing via coretimer, which, in most cases (see HZ in .config) give us ticks every 4ms (250Hz).
(1)If DAHDI have a master span and at least one dahdi_receive call for 4ms - DAHDI will think the timer is OK.
dahdi_receive->_process_masterspan->atomic_inc(&core_timer.count)
(2)If DAHDI have no master span, or no dahdi_receive calls - DAHDI will call _process_masterspan 4 times every 4ms.
		while (ms_since_start > msecs_processed(&core_timer))
			_process_masterspan();

So, case (1):
DAHDI will have excellent timing source (1ms)
or
DAHDI will have an awfull timing source (in the worst case, 3.9999ms, so, 250Hz instead of 1000Hz).
Yes, it's possible. It's a bug, but it's rare.
	if (atomic_read(&core_timer.count) ==
	    atomic_read(&core_timer.last_count)) {
	} else {
		atomic_set(&core_timer.count, 0);
		atomic_set(&core_timer.last_count, 0);
		core_timer.start_interval = now;
	}

case (2)
DAHDI will call _process_masterspan 4 times every 4ms.
It will be good for asterisk (queue), but bad for TDMoE, if hardware have rx FIFO less than 5ms.

== What will you patch bring us?
If kernel have HIGHRESTIMER, 
dahdi_hr_int will be called every 1S to check, if there was at least one tick from master SPAN.
dahdi_hr_int will be called every 1mS if no ticks from master span.

	if (atomic_read(&core_timer.count) == atomic_read(&core_timer.last_count)) {
		_process_masterspan();
	} else {
		/* board driver is spinning DAHDI, relax, check back in 1 second */
		if (debug)
			printk(KERN_DEBUG "dahdi_hr_int: slow hrtimer tick\n");

		hrtimer_forward(htmr, hrtimer_get_expires(htmr), ktime_set(1, 0));

		if (!core_timer.dahdi_receive_used) {
			core_timer.dahdi_receive_used = 1;
			printk(KERN_NOTICE "dahdi_hr_int: disabled master core hrtimer\n");
		}
	}
So,
DAHDI will have excellent timing source (1ms)
or
DAHDI will have an awful timing source (in the worst case, 999ms, so, 1Hz instead of 1000Hz).

What configuration can we have with TDMoE ?
(1) Two TDMoE devices, master, master.
(2) Two TDMoE devices, slave, master.
(3) non-dynamic SPAN, one TDMoE device. slave, master.

(1) - We need either you patch with HIGHRESTIMER, or dahdi_dummy device (with HIGHRESTIMER also) to provide timing for TDMoE.
(2) - We don't need "software" timing, as we'll get it from TDMoE device.
(3) - We don't need "software" timing, as we'll get it from non-dynamic SPAN device.

Neither patched, nor original dahdi-base will not let TDMoE device became "(MASTER)" SPAN.
It's sad, as it is widely used on our hardware...
		if (!can_provide_timing(s))
			continue;

I think, it's better to leave dahdi's timing as is, but enable dahdi_dummy in Makefile.
1. It’s rare situation (one of three).
2. dahdi-base is 285kb of (dirty) code, with a lot of #if #else #endif. That’s enougth.
Classic joke: 
#define i j /* Wish you happy debugging. */

It’s better to use dummy instead. Changes are minimal.
find_master should look like this (obsole code):
static void __dahdi_find_master_span(void)
{
	struct dahdi_span *s, *old_master, *new_master = NULL;
	unsigned long flags;

	spin_lock_irqsave(&chan_lock, flags);
	old_master = master;
        /* Searching for the FIRST reliable sync source with reverse for. */
	list_for_each_entry_reverse(s, &span_list, spans_node) {
		if (!can_provide_timing(s) || s->alarms)
			continue;
		if (dahdi_is_digital_span(s) &&
		    !test_bit(DAHDI_FLAGBIT_RUNNING, &s->flags))
			continue;
		if ((0 == s->channels) && !new_master)	/* dummy is better than nothing (coretimer). */
			new_master = s;
		new_master = s;	/* But real span is better than dummy. */
	}
	master = new_master;
	spin_unlock_irqrestore(&chan_lock, flags);

	if ((debug & DEBUG_MAIN) && (old_master != master))
		module_printk(KERN_NOTICE, "Master changed to '%s'\n",
			      master ? master->name : "no master (core timer)");
}

That's all up to the timing in dahdi-base.
I’ll write about dynamic in 4 hours.
Thank you.

> 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-dynamic-multispan-fifo.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