[asterisk-dev] Re: TDMoE protocol

[James Harper]

> In article <AEC6C66638C05B468B556EA548C1A77DAF09E2 at trantor>,
> James Harper <james.harper at bendigoit.com.au> wrote:
> >
> > > Paul Cadach mentioned something about a jitter buffer for TDMoE,
but
> > > I don't know whether he was talking about an idea or some real
code.
> > >
> > > I'm also thinking about a jitter buffer, but it's tricky. I might
> > > decide to combine ztdummy with ztdynamic/ztd_eth in order to make
the
> > > timing independent of incoming packets or other zaptel devices.
The
> > > jitter buffer only needs to be 1ms or 2ms in length.
> >
> > A jitter buffer adds delay though right? I guess 2ms fixed delay
> > shouldn't cause a problem, but how would it work if tdmoe is your
only
> > source of timing? Is the 2.6 version of ztdummy widely held to be
> > precise enough for our use?
> 
> As the one who added 2.6 RTC support to ztdummy, I'm qualified to
comment!
> The primary reason for ztdummy is to support SIP, IAX and MeetMe in a
> system with no Zaptel cards. It is quite adequate for that, although
> there is a patch on the bugtracker that aims to address a perceived
> weakness in it.
> 
> However, I don't think ztdummy as it stands is quite accurate enough
> for governing TDMoE, because it doesn't maintain a 1ms spacing. Since
> the RTC can only do power-of-2 subdivisions of a second, it is set to
> 1/1024 sec (0.9765625ms), but then 3 interrupts out of every 128 are
> skipped (evenly spaced) to give an average of 1000 per second. This
> is ok for VoIP with a 20ms or 30ms frame size, but not for TDMoE with
> a packet every 1ms. I would probably try making ztdummy use 4096 RTC
> interrupts per second and skip 3096 of them. This would make the
> interval between two consecutive packets either 0.9765625ms or
> 1.220703125ms.

I've always wondered how you got 1000 ticks out of 1024 without a bit of
inaccuracy. So if you are skipping 3 ticks per 1024, 3 intervals are
going to be ~1.8ms apart. I can see why that would be a problem!

What do you see as being the overhead of doing 4096 interrupts/second,
given that the handler for at least 3096 of them is going to be _very_
fast? Any reason why not to go to 8192?

Also, doesn't the 2.6 kernel run on 1khz timing? Why isn't this used
(I'm sure there's a good reason, I'm just curious to know what it is!)?

Thanks

James