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

[Oron Peled]

On Wednesday, 2 בMay 2007 22:15, Matthew Fredrickson wrote:
> On May 2, 2007, at 12:55 PM, Paul Cadach wrote:
> > Tzafrir Cohen wrote:
> >>  int (*sync_tick)(struct zt_span *span, int is_master);
> > Is it better to have a call to such API every N (1000, 10000) ticks? 
> Yes, I tend to agree with these observations.  Assuming the hardware 
> does have support for timing adjustments such as this, 1000 times per 
> second of timing update is most definitely overkill.

The patch sent by Tzafrir was designed to minimize the zaptel API
change and thus the impact on all zaptel users who *don't* have
this feature (most if not all current zaptel cards).
(To remove any doubts these decisions are my fault, not Tzafrir's).

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]

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? */

      [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).

      [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].

[to remove any doubt, if you like these proposals I'm willing to do
 the implementation]

Remarks? Logical bugs? Improvements?

-- 
Oron Peled                             Voice/Fax: +972-4-8228492
oron at actcom.co.il                  http://www.actcom.co.il/~oron
ICQ UIN: 16527398

Reality must take precedence over public relations, for Mother 
Nature cannot be fooled.  -- R.P. Feynman