[asterisk-dev] Alternative Clock Source

[Paulo Garcia]

Hi Michael,

first, thanks for you answer.

The idea is to provide my own clock source to Asterisk since our hardware
has its own clock source and I don't use any "zaptel" hardware.

Our hardware isn't zaptel dependent then I thought that is possible to
provide the clock without the need to install any zaptel software. Well, I
think it is still possible but the work involved is much bigger than use
ztdummy interface to do it.... And AFAIK, I always will need to patch
something...

Also, I need to clarify what do you mean when said "to provide channels".
Could you please?


Thanks!


Paulo Garcia




On 6/7/07, Michael Cargile <mcargile at explido.us> wrote:
>
> On Thu, 2007-06-07 at 09:05 -0300, Paulo Garcia wrote:
> > Hi,
> >
> > I'm currently study the alternatives I can use to implement an
> > alternative clock source for Asterisk. After some research I found two
> > options some developers are doing.
> >
> > The first solution is described on Digium's bug tracker
> > (http://bugs.digium.com/view.php?id=8896). The idea is to use a
> > patched ztdummy with a new module. This module will register itself to
> > ztdummy and it will implement the interrupt handler. Since ztdummy is
> > already registered to zaptel, my clock will be used. This solution is
> > being used with mISDN driver.
> >
> > The second solution is to make a ztdummy "clone" with my code
> > controling the clock.... The idea is very similar to the first one but
> > the ztdummy-clone will register itself directly to zaptel. I'll need
> > to patch zaptel's Makefile to compile my "clone" and so on….Ztxen uses
> > this solution (XEN virtualization).
> >
> > Both options are very similar and they need to keep zaptel device
> > driver running to do it.
> >
> > I'd like to know if there are another alternative which doesn't need
> > zaptel.
> >
> > Any information will be useful!
>
> Being the person who did the initial work on ztxen I can give you info
> on why we choose the second approach. The big thing with ztxen is that
> we want to pass the timing in from the host system into the virtual
> machine so that if the host system has a stable zaptel timer it uses
> that instead of the kernel interrupt (XEN virtual machines have no RTC).
> Also we want to actually be able to pass from the host machine any
> zaptel channels through ztxen to the virtual machines. We will be
> implementing this in the not to distant future. Right now ztxen is
> nothing more than ztdummy without the RTC stuff.
>
> If the only thing we were doing was providing timing and no channels to
> the virtual machine we probably would have just created a module for
> ztdummy like in the first solution. So my personal opinion is that if
> you are just getting a timing source augment ztdummy to use it. If you
> are going to be providing channels create your own module.
>
> Personally I think it would be really neat to make ztdummy take some
> options on load that would allow you to choose which timer it should
> use. The three I can think of off the top of my head are the RTC, the
> kernel interrupt, and the USB subsystem.
>
> Well that's my 2 cents.
>
> Michael Cargile
> Explido Software USA Inc.
> www.explido.us
>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>



-- 
--------------
Paulo Garcia
Pika Technologies Inc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20070607/3f6e9e20/attachment.htm