[asterisk-dev] DAHDI timing source cleanup proposal

[Pavel Selivanov]

Dear Sirs,

For a long time, timing in DAHDI driver was horror.
There are no method to specify, which SPAN is going to be the (clock)
master for DAHDI,
thus, you can not be sure, you will get what you want.

The same time, dahdi_dynamic have it's own master, with an arbitrage,
and its arbitrage seems good.
But, this mean, you can get 2 different (clock) masters, and it's terrible.
Also, if you have 2 not-synchronized cards, you will get slips/skips
deep inside DAHDI, and you will not know this (no stats at all).
You will hear it or you will see problems with FAX.

Some time ago, I've made a simple patch:
https://issues.asterisk.org/view.php?id=13205
It was a first step, and it's working as expected in many instances.

My proposal is to rework timing in DAHDI (to make second step).

= Terms
    MASTER (Global Master) - master SPAN for DAHDI
        this SPAN will provide timing to DAHDI, and DAHDI will expect
chunks from other SPANS synced with MASTER span.
    ClockSource - master SPAN withing multichannel card.
        Any multichannel card have one internal bus, only one channel
will be a ClockSource for the whole card.

= Types of SPANS
    Real SPAN - SPAN that represent a real device.
        It can provide timing.
    Virtual SPAN - SPAN that don't represent a real device.
        It can also provide timing. It's channels number == 0.
        dahdi_dummy
    No-Timing-SPAN - SPAN that can't provide timing.
        I think, we can use flags existing flags for that (flags &=
FLAGS_RUNNING)
        dahdi_dynamic_loc

= Arbitrage
    On SPAN registration, DAHDI must search for a master (checkmaster).
    On SPAN's state change, device driver must notify alarm to DAHDI
(already done this way).
        DAHDI call checkmaster if necessary.
    On SPAN removal, DAHDI must call checkmaster, if necessary.

In system.conf we've got timing source option for SPANS & dynamic SPANS.
We can use it the same way, it's used in dahdi_dynamic, but globally.

Arbitrage:
    Searching for a non-alarm SPAN with flag FLAGS_RUNNING.
    Using SPAN with the lowest timing priority, with channels != 0 as a
MASTER.
    If we've got no - searching for a zero channels SPAN (dahdi_dummy).

I think, we shouldn't differ cards with a timing cable, cards without
timing cable, dynamic span devices.
Any 2 cards can have "external timing cable" - we can connect
card1:line4 with card2:line1, and
span=1,1,0, span=2,0,0, span=3,0,0, span=4,0,0
span=5,2,0, span=6,0,0, span=7,0,0, span=8,0,0
So, SPAN1 will receive sync from TELCO, SPAN5 will receive sync from
SPAN4(from TELCO).
Card1 & card2 will be in sync, but DAHDI will know nothing about it...
But the user will.

Lets examine sync source on multiport cards.
span=1,1,0, span=2,0,0, span=3,0,0, span=4,0,0 #card1
span=5,2,0, span=6,0,0, span=7,0,0, span=8,0,0 #card2
card1 will use port1 (SPAN1) a sync source for the whole card. It's good.
card2 will use port1 (SPAN5) a sync source for the while card.
SPAN1 will be the "Global Master", and all cards will be in sync with it.

dahdi_dynamic devices, XPP devices.
This devices can be both, timing slave (adjustable oscillator) and
timing master for DAHDI.

DAHDI & dahdi_dynamic should copy dahdi_lineconfig->sync to span->sync.
So, our patch will not affect existing drivers, letting DAHDI to use
timing field as it should be.

After checkmaster will be implemented - it can be removed from
dahdi_dynamic, and the whole DAHDI will be in sync.