libertas-dev Digest, Vol 32, Issue 26

[Kareem Shehata]

Good post... from the future!  Either that, or my clock is off by > 20  
minutes.

Just finishing up lunch, should be there soon.

-kms


On 28-Feb-2009, at 12:00, libertas-dev-request at lists.infradead.org  
wrote:

> Send libertas-dev mailing list submissions to
> 	libertas-dev at lists.infradead.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.infradead.org/mailman/listinfo/libertas-dev
> or, via email, send a message with subject or body 'help' to
> 	libertas-dev-request at lists.infradead.org
>
> You can reach the person managing the list at
> 	libertas-dev-owner at lists.infradead.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of libertas-dev digest..."
>
>
> Today's Topics:
>
>  1. Slow Wifi... getting closer (Dave Kroetsch)
>  2. Re: Slow Wifi... getting closer (Daniel Mack)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 27 Feb 2009 12:39:59 -0500
> From: Dave Kroetsch <dave at aeryon.com>
> Subject: Slow Wifi... getting closer
> To: libertas-dev at lists.infradead.org
> Message-ID: <49A8256F.9010901 at aeryon.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hey all,
>
> Ok, so I'm getting much closer to the root of this wifi slow down with
> local UDP traffic.  I've tried putting printk's in the lbs_thread to  
> see
> how often it was being called, but this alone slows down traffic
> dramatically.  My theory is that this is due to the fact that the  
> printk
> hands the task of printing and logging this message to another kernel
> thread and this, therefore, mucks up the thread scheduling of the
> lbs_main thread, resulting in slow transfers.
>
> To decouple the printk's from the scheduling problem, I've set up the
> driver to blink an LED each time it enters the lbs_main thread.  So, I
> begin a transfer, and see lots of blinking activity.  When I start the
> UDP test this grinds to a halt - indicating that the thread is not  
> being
> scheduled as often as it should.
>
> Anyone got any suggestions on what can be done to make sure this  
> thread
> gets scheduled with higher priority?  Trying a sched_setscheduler  
> causes
> an Oops, and I don't have any RT patches installed to play with that  
> stuff.
>
> Thanks,
> 	Dave
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 27 Feb 2009 18:46:13 +0100
> From: Daniel Mack <daniel at caiaq.de>
> Subject: Re: Slow Wifi... getting closer
> To: Dave Kroetsch <dave at aeryon.com>
> Cc: libertas-dev at lists.infradead.org
> Message-ID: <20090227174613.GC8855 at buzzloop.caiaq.de>
> Content-Type: text/plain; charset=us-ascii
>
> On Fri, Feb 27, 2009 at 12:39:59PM -0500, Dave Kroetsch wrote:
>> Ok, so I'm getting much closer to the root of this wifi slow down  
>> with
>> local UDP traffic.  I've tried putting printk's in the lbs_thread  
>> to see
>> how often it was being called, but this alone slows down traffic
>> dramatically.  My theory is that this is due to the fact that the  
>> printk
>> hands the task of printing and logging this message to another kernel
>> thread and this, therefore, mucks up the thread scheduling of the
>> lbs_main thread, resulting in slow transfers.
>
> Just a general note in the hope be helpful: for debugging such fast  
> path
> code I found it handy to simply use counters in the places you want to
> trace and then use a timer and dump them once a second (and probably
> reset them). printk() happens to be expensive - especially on embedded
> machines - and might also loose entries on message buffer overruns.
>
> Daniel
>
>
>
>
> ------------------------------
>
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev
>
>
> End of libertas-dev Digest, Vol 32, Issue 26
> ********************************************

--
Kareem Shehata
Aeryon Labs Inc.
519-489-6726 x254
http://aeryon.com