Re: [Cerowrt-devel] debugging sip udp weirdness in 3.3.[68]

[Dave Taht <dave.taht@gmail.com>]

On Fri, Aug 10, 2012 at 12:55 PM,  <dpreed@reed.com> wrote:
> diffserv does not propagate well in the Internet outside.   I would be
> surprised if diffserv helped much at all in a typical "home network
> accessing a high speed Internet access provider" scenario.

In this case EF marked packets on the inside of the home network
are being sent into the wifi VO queue, which has desirable properties.

(if it wasn't for bug 401 showing up - now fixed, but I need to put a
new release together)

Part of why I wanted a tcpdump was to see what markings were
being used by the app and what was being returned from the call.


>
>
>
> There is NO interprovider standard for handling diffserv - so it's like
> setting the "behave randomly" knob to 11.

Heh. Actually one overall goal is to determine how randomly even well
agreed upon markings are actually handled...

>
>
>
> -----Original Message-----
> From: "Dave Taht" <dave.taht@gmail.com>
> Sent: Friday, August 10, 2012 2:06pm
> To: "Michael Mee" <mm2001@pobox.com>
> Cc: cerowrt-devel@lists.bufferbloat.net
> Subject: Re: [Cerowrt-devel] debugging sip udp weirdness in 3.3.[68]
>
> On Thu, Aug 9, 2012 at 6:07 PM, Michael Mee <mm2001@pobox.com> wrote:
>> [Hoping to help with feedback, but not sure if this is the right place.
>> Apologies and please redirect me if so!]
>>
>> When I run the stock Android Jelly Bean SIP client (part of the dialer)
>> over my Netgear WNDR3800 on 2.4g (CEROwrt) with 3.3.8 (and also 3.3.6
>> prior), the conversations are poor. It sounds like packets are being
>> dropped all over the place. This is despite plenty of bandwidth
>> available (ADSL2 at 15 x 1.5Mbps, IPv4). Other (generic, non-CEROwrt)
>> wireless networks I've tried work well, as does the 4G or 3G service
>> from my phone. I'm running the GSM codec which consumes about 30kbps.
>> This is a vanilla SIP connection, using UDP. It doesn't happen all the
>> time - about 50% (+/- 25%!) of calls.
>
> Yes, this is interesting.
>
> Are you using QoS on the outgoing link at all?
>
> One bug that cropped up in releases prior to 3.3.8-11 was that the VI and BK
> portions of the wireless spectrum were being "interestingly" stomped
> on by the ath9k driver.
>
> http://www.bufferbloat.net/issues/402 and 401
>
> As cerowrt is now doing extensive diffserv classification on wifi this
> could possibly affect voip significantly. (the problem was generic to
> the ath9k driver however)
>
> I'm not ready with a new release of cerowrt yet, however.
>
> Also we were using some settings for codel that were suboptimal. In
> fact it's increasingly likely that no setting on the current fq_codel
> is optimal in the spot on the wifi driver stack it's at.
>
>
>> If this is interesting to anyone and I can help debug it by providing
>> more information, I'm happy to. Or, feel free to say "Doh, of course it
>> doesn't work, this is beta software at best. Go away!"
>
> Oh, no, making sure wifi voip works well is very high on our priority list.
>
> tcpdump a test stream (I can provide detailed syntax) and we can look
> at the drop pattern.
>
>>
>> thanks, Michael
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
>
> --
> Dave Täht
> http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-6 is out
> with fq_codel!"
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht
http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-6 is out
with fq_codel!"