[asterisk-dev] M9645: provide zaptel master timing to spans

[Tzafrir Cohen]

On Sun, May 06, 2007 at 12:52:49AM +0300, Oron Peled wrote:

> If we look for a better API, than we should expand this a little bit:
> 1. Zaptel should notify interested drivers about sync-master changes.
>    For example via an optional span method:
>         int (*sync_master_change)(struct zt_span *span, int you);
>    Whenever zaptel elects different sync-master, it should call
>    this method twice -- first, to the old master with you==0
>    and than to the new master with you==1
> 
> 2. As suggested by Paul Cadach, the call rate should be lower
>    and *adjustable*, so we should change sync_tick() to something
>    like:
> 	int (*sync_tick)(struct zt_span *span, unsigned long ticknum);
>    [the is_master parameter isn't required anymore because of the
>     notification mechanism]

Note that for the proposed ztxen driver, the current rate is needed: the
driver that runs at the host needs to pass every tick to the guests.

> 
> 3. The tick rate could be exposed as a command line parameter to zaptel
>    and may be adjusted at runtime (via /sys/module/zaptel/paramters/...)
> 
> 4. While the previous 3 items may be enough for this, I suggest that at
>    this opportunity we may at last implement some priorities into zaptel
>    master selection.
>    The current zt_register(struct zt_span *span, int prefmaster) API is
>    enough. However, the following implementation changes are needed IMO:
>    A. The 'prefmaster' parameter should be interpreted as priority and
>       remembered. This may be done without breaking backward source
>       compatibility by using some predefined enumerated priorities. E.g:
> 
>   #define SYNC_FALLBACK 0  /* take me if there's nothing better */
>   #define SYNC_INTERNAL 1  /* I have good internal clock        */
>   #define SYNC_EXTERNAL 2  /* PRI and BRI synced from phone network */
>   /* any other? */

I would space them a bit:

#define SYNC_FALLBACK 0    /* take me if there's nothing better */
#define SYNC_INTERNAL 1    /* I have good internal clock        */
#define SYNC_EXTERNAL 10   /* PRI and BRI synced from phone network */

To allow a bit more fine tuning and manual prioritzing between devices.

> 
>       [currently all zaptel drivers use either 0 or 1, so it's OK]
> 
>    B. Currently there's no API that enable a driver to "regret"
>       its choice as sync-master after zaptel registration. It would
>       be good if zaptel exported a function like:
> 	int sync_election(struct zt_span *span, int priority);
>       to allow this (the return value would indicate to the span
>       if it got mastership or not).

This currently happens implicitly in zt_alarm_notify . When there is an
alarm on the master span, relections happen.

Should the two be separated?

> 
>       [If this function is implemented, than obviously it would be
>        automatically called from the end of zt_register() and so
>        would eliminate code duplication in zaptel].

-- 
               Tzafrir Cohen       
icq#16849755                    jabber:tzafrir at jabber.org
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com       
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir