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 <[email protected]> wrote: From: Eddie Kohler <[email protected]> Subject: Re: [Click] Multithreaded question To: [email protected] Cc: "Click Mailinglist" <[email protected]> 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 [email protected] 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 > > > > > > ------------------------------------------------------------------------ > _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
