Increasing delay in Meetme with ztdummy

Hi,

I have asterisk 1.4.17_1 running fine on my 7.0-STABLE
machine with
zaptel-1.4.6_4. Everything is working great, except for
Meetme conferences
which start out fine, but delays increases further and
further as time
goes by. This is on an 8-core Dell Poweredge 1950 which
really should
handle the load (as it's only doing this job). I can confirm
that
ztdummy.ko is loaded properly. I have HZ=1000 in my kernel
and SCHED_ULE.

I tried playing with kern.timecounter.hardware to no avail.
I also tried
the ztdummy.c and channel.c patch from this thread:
http://lists.digium.com/pipermail/asterisk-b
sd/2007-July/002756.html

I'm out of options... so if anyone can help me, it would
greatly be
appreciated.

Nicolas.


_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

Asterisk-BSD mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-bsd

On Sat, Mar 1, 2008 at 5:32 AM, Nicolas Blais
<nicblaisclkroot.net> wrote:
>  I have asterisk 1.4.17_1 running fine on my 7.0-STABLE
machine with
>  zaptel-1.4.6_4. Everything is working great, except
for Meetme conferences
>  which start out fine, but delays increases further and
further as time
>  goes by. This is on an 8-core Dell Poweredge 1950
which really should
>  handle the load (as it's only doing this job). I can
confirm that
>  ztdummy.ko is loaded properly. I have HZ=1000 in my
kernel and SCHED_ULE.

I was able to fix the problem using only the information
included here:

ports/115059

http://www.freebsd.org/cgi/query-pr.cgi?pr=115059
&cat=ports

Of course this patch is against 1.4.6 on FreeBSD
6.2-RELEASE-p4...

-Corey Smith

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

Asterisk-BSD mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-bsd

> On Sat, Mar 1, 2008 at 5:32 AM, Nicolas Blais
<nicblaisclkroot.net>
> wrote:
>>  I have asterisk 1.4.17_1 running fine on my
7.0-STABLE machine with
>>  zaptel-1.4.6_4. Everything is working great,
except for Meetme
>> conferences
>>  which start out fine, but delays increases further
and further as time
>>  goes by. This is on an 8-core Dell Poweredge 1950
which really should
>>  handle the load (as it's only doing this job). I
can confirm that
>>  ztdummy.ko is loaded properly. I have HZ=1000 in
my kernel and
>> SCHED_ULE.
>
> I was able to fix the problem using only the
information included here:
>
> ports/115059
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=115059
&cat=ports
>
> Of course this patch is against 1.4.6 on FreeBSD
6.2-RELEASE-p4...
>
> -Corey Smith
>

I tried that patch (it was included in the thread I
mentionned). I did see
an improvement, such as the delay getting up to 3 seconds,
but not worse
after that.

Nicolas.


_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

Asterisk-BSD mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-bsd

> > I was able to fix the problem using only the
information included here:
> >
> > ports/115059
> >
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=115059
&cat=ports
> >
> > Of course this patch is against 1.4.6 on FreeBSD
6.2-RELEASE-p4...
> >
> > -Corey Smith
> >
> 
> I tried that patch (it was included in the thread I
mentionned). I did see
> an improvement, such as the delay getting up to 3
seconds, but not worse
> after that.

   That suggests that you didn't have the channel.c patch
properly applied.

-DG

Dr. David G. Lawrence
President
Download Technologies, Inc. - http://www.downloadtech.c
om - (866) 399 8500
The FreeBSD Project - http://www.freebsd.org
Pave the road of life with opportunities.

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

Asterisk-BSD mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-bsd

>> > I was able to fix the problem using only the
information included
>> here:
>> >
>> > ports/115059
>> >
>> > http://www.freebsd.org/cgi/query-pr.cgi?pr=115059
&cat=ports
>> >
>> > Of course this patch is against 1.4.6 on
FreeBSD 6.2-RELEASE-p4...
>> >
>> > -Corey Smith
>> >
>>
>> I tried that patch (it was included in the thread I
mentionned). I did
>> see
>> an improvement, such as the delay getting up to 3
seconds, but not worse
>> after that.
>
>    That suggests that you didn't have the channel.c
patch properly
> applied.
>
> -DG
>
> Dr. David G. Lawrence
> President
> Download Technologies, Inc. - http://www.downloadtech.c
om - (866) 399 8500
> The FreeBSD Project - http://www.freebsd.org
> Pave the road of life with opportunities.
>

I was certain I saw both hunks successfully applied but I
will try again
tomorrow and will report back on the results.

Thanks for your help!

Nicolas.



_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

Asterisk-BSD mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-bsd

>> > I was able to fix the problem using only the
information included
>> here:
>> >
>> > ports/115059
>> >
>> > http://www.freebsd.org/cgi/query-pr.cgi?pr=115059
&cat=ports
>> >
>> > Of course this patch is against 1.4.6 on
FreeBSD 6.2-RELEASE-p4...
>> >
>> > -Corey Smith
>> >
>>
>> I tried that patch (it was included in the thread I
mentionned). I did
>> see
>> an improvement, such as the delay getting up to 3
seconds, but not worse
>> after that.
>
>    That suggests that you didn't have the channel.c
patch properly
> applied.
>
> -DG
>
> Dr. David G. Lawrence
> President
> Download Technologies, Inc. - http://www.downloadtech.c
om - (866) 399 8500
> The FreeBSD Project - http://www.freebsd.org
> Pave the road of life with opportunities.
>

Hi,

I checked channel.c and the patch from
(http://lists.digium.com/pipermail/asterisk-b
sd/2007-July/002797.html) was
correctly applied, both hunks. Asterisk was compiled from a
clean build
thereafter with everything in order.

I also confirmed that the "fixed" ztdummy.ko is
also in and running.

Is there anything else I can check?

Thanks,
Nicolas.


_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

Asterisk-BSD mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-bsd

> Hi,
> 
> I checked channel.c and the patch from
> (http://lists.digium.com/pipermail/asterisk-b
sd/2007-July/002797.html) was
> correctly applied, both hunks. Asterisk was compiled
from a clean build
> thereafter with everything in order.
> 
> I also confirmed that the "fixed" ztdummy.ko
is also in and running.
> 
> Is there anything else I can check?

   The patch to channel.c was written originally for
Asterisk 1.2.x. I
would think it would be compatible with 1.4.x, but perhaps
not. It is
supposed to limit the queue depth on input frames to 3 or so
to
prevent a large latency from developing.
   The replacement ztdummy changes the way that timing is
done to use
the time of day clock instead of the interval clock, and has
the affect
of keeping timing in sync with other VoIP peers and the
PSTN.
   It might be helpful if you described your specific setup
(phones,
server hardware, PSTN connection, etc). Assuming that you
haven't made
any mistakes on the Asterisk end, the problem sounds like it
might be
with external devices that you're using.

-DG

Dr. David G. Lawrence
President
Download Technologies, Inc. - http://www.downloadtech.c
om - (866) 399 8500
The FreeBSD Project - http://www.freebsd.org
Pave the road of life with opportunities.

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

Asterisk-BSD mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-bsd

>> Hi,
>>
>> I checked channel.c and the patch from
>> (http://lists.digium.com/pipermail/asterisk-b
sd/2007-July/002797.html)
>> was
>> correctly applied, both hunks. Asterisk was
compiled from a clean build
>> thereafter with everything in order.
>>
>> I also confirmed that the "fixed"
ztdummy.ko is also in and running.
>>
>> Is there anything else I can check?
>
>    The patch to channel.c was written originally for
Asterisk 1.2.x. I
> would think it would be compatible with 1.4.x, but
perhaps not. It is
> supposed to limit the queue depth on input frames to 3
or so to
> prevent a large latency from developing.
>    The replacement ztdummy changes the way that timing
is done to use
> the time of day clock instead of the interval clock,
and has the affect
> of keeping timing in sync with other VoIP peers and the
PSTN.
>    It might be helpful if you described your specific
setup (phones,
> server hardware, PSTN connection, etc). Assuming that
you haven't made
> any mistakes on the Asterisk end, the problem sounds
like it might be
> with external devices that you're using.
>
> -DG
>
> Dr. David G. Lawrence
> President
> Download Technologies, Inc. - http://www.downloadtech.c
om - (866) 399 8500
> The FreeBSD Project - http://www.freebsd.org
> Pave the road of life with opportunities.
>

I am using Cisco 7940 phones and the X-lite softphones. Both
exhibit the
same behavior (the delay starts out correct, and grows
longer until it
reaches about 3 seconds).

This is a sample sip.conf entry for my 7940s and for
X-Lite:

[4120] ;(7940)
type = friend
callwaiting = yes
cid_number = 4120
context = numberplan-custom-1
email = NONE
fullname = CONF RM
hasvoicemail = yes
host = dynamic
mailbox = 4120
secret = 4120
vmsecret = 1234

[4220] ;(X-Lite)
type = friend
callwaiting = yes
cid_number = 4220
context = numberplan-custom-1
email = NONE
fullname = CONF RM
hasvoicemail = yes
host = dynamic
mailbox = 4220
secret = 4220
vmsecret = 1234
disallow = all
allow = ilbc
allow = gsm
allow = ulaw
allow = alaw

I have left everything in zapata.conf default (nothing added
or removed)
and zaptel.conf only has:
loadzone = us
defaultzone = us

My setup is pretty simple, all I got are Cisco 7940/X-Lite
phones that
work very well together, and ztdummy for MeetMe.

Thanks,
Nicolas.


_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

Asterisk-BSD mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-bsd

> I am using Cisco 7940 phones and the X-lite softphones.
Both exhibit the
> same behavior (the delay starts out correct, and grows
longer until it
> reaches about 3 seconds).

   3 seconds is a delay of about 150 voice frames. This
shouldn't be
possible with the channel.c patch, but perhaps Asterisk
1.4.x has another
queue somewhere (dynamic jitter buffer??). I guess there
could be some
queueing going on in MeetMe as well.
   I'm still using 1.2.x on all of our VoIP servers, so I
can't really
confirm proper behavior on 1.4.x.
 
> I have left everything in zapata.conf default (nothing
added or removed)
> and zaptel.conf only has:
> loadzone = us
> defaultzone = us
> 
> My setup is pretty simple, all I got are Cisco
7940/X-Lite phones that
> work very well together, and ztdummy for MeetMe.

   That all looks fine. Is your server running NTP and is it
synced
with a stable network clock? Also, just to confirm, you
never have
this problem on calls between extensions (through Asterisk)
when not
using MeetMe?

-DG

Dr. David G. Lawrence
President
Download Technologies, Inc. - http://www.downloadtech.c
om - (866) 399 8500
The FreeBSD Project - http://www.freebsd.org
Pave the road of life with opportunities.

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

Asterisk-BSD mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-bsd

>> I am using Cisco 7940 phones and the X-lite
softphones. Both exhibit the
>> same behavior (the delay starts out correct, and
grows longer until it
>> reaches about 3 seconds).
>
>    3 seconds is a delay of about 150 voice frames. This
shouldn't be
> possible with the channel.c patch, but perhaps Asterisk
1.4.x has another
> queue somewhere (dynamic jitter buffer??). I guess
there could be some
> queueing going on in MeetMe as well.
>    I'm still using 1.2.x on all of our VoIP servers, so
I can't really
> confirm proper behavior on 1.4.x.
>

That number (150 voice frames) woke something up in my head.
I have
attached a short except from the patched channel.c. If you
look below your
added code, you see a portion of code which seems to allow
up to 96 voice
frames outstanding. Could this be related to my problem?

>> I have left everything in zapata.conf default
(nothing added or removed)
>> and zaptel.conf only has:
>> loadzone = us
>> defaultzone = us
>>
>> My setup is pretty simple, all I got are Cisco
7940/X-Lite phones that
>> work very well together, and ztdummy for MeetMe.
>
>    That all looks fine. Is your server running NTP and
is it synced
> with a stable network clock? Also, just to confirm, you
never have
> this problem on calls between extensions (through
Asterisk) when not
> using MeetMe?
>

I do run NTP and the drift is very low. I tried to
"fudge" the clock and
make myself the reference (therefore a drift of 0) but it
doesn't change
anything on Asterisk's side or my problem.  And yes, I
confirm that
everything is working surprisingly well except for only
MeetMe.

Again, your help is really appreciated.
Nicolas.
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

Asterisk-BSD mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-bsd