[Click] Multithreaded question

[R H]

Thanks Eddie.

We managed quite well with a single thread.  And now we have much better understanding of click's scheduling/threading internals.

The issue with burstiness:  We had an active element with a requirement to produce a packet every 10ms, we had a timer and task scheduling combined.  We placed it in its own thread using StaticThreadSched.  Under load, the producer sometimes sends more than a packet, other times misses the 10ms mark.  

Even when moving the logic to a separate executable running independent of click, we still had the same results until we up'ed the thread's priority to its highest level and ensured no services kick-in when running...

Thanks again for your help,
Raja  

--- On Sat, 2/27/10, Eddie Kohler <kohler at cs.ucla.edu> wrote:

From: Eddie Kohler <kohler at cs.ucla.edu>
Subject: Re: [Click] Multithreaded question
To: rajamhayek at yahoo.com
Cc: "Click Mailinglist" <click at amsterdam.lcs.mit.edu>
Date: Saturday, February 27, 2010, 5:23 PM

Hi Raja,

For some discussion on the "best" way to assign tasks to threads, see the paper by Chen and Morris, "Flexible COntrol of Parallelism...".

As for your 1-4, the thing about queues is that they are in *both* a push region *and* a pull region; that is their entire point.  Queues are passive elements and do not beling to threads themselves.  So your 2-4 options don't really make sense.

FWIW at Intel's Routebricks project we have found it valuable to ensure that only one core touches a packet on its entire path through the router. Parallelism is achieved by having separable paths.

As for bursty behavior, hard to know there what you mean either.  Were you using StaticThreadSched?  BalancedThreadSched?  If you didn't use either, then in your multithreaded program only one thread was doing all the work.

Eddie


rajamhayek at yahoo.com wrote:
> Hi Eddie,
> 
> I am not sure how the threading/stride scheduling work together.  I have included a sample image, extracted from a Master's thesis, that describe the single threaded execution.  In this picture, the active elements (A1, A2, and A3) are scheduled to run in sequence.  When they do run, they call synchronously the elements they are connected to until a queue (passive element) is reached.  This decomposes the execution into push/pull regions. Now we want to move this to multithreaded execution, what is the best way of adding elements to threads:
> 
> 1- Only the active elements run on threads.
> 2- The full regions are assigned to threads and the queues remain in the main thread.
> 3- The full regions are assigned to threads and the queues are in the push region.
> 4- The full regions are assigned to threads and the queues are in the pull regions.
> 
> So far with our application, assigning only active elements to threads, we are getting an unwanted bursty behavior of packet.  In single threaded, the bursty behavior disappears but we do not reach the required throughput.  I appreciate any pointers that can help us resolve this problem.
> 
> Thank you,
> Raja
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
>