discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] gr-ieee 802.11 and threads for real time


From: Dennis Glatting
Subject: Re: [Discuss-gnuradio] gr-ieee 802.11 and threads for real time
Date: Wed, 02 Nov 2016 10:34:33 -0700

On Wed, 2016-11-02 at 06:41 -0700, sumitstop wrote:
> Hello,
> 
> I am in the process of constructing my own 802.11 receiver using C
> and UHD. I was looking at the implementation of gr-ieee 802.11. 
> 
> I am trying to figure out how many parallel threads it is using for
> the receiver and transmitter. In order to work in real time,
> especially decoding 802.11 packets in real time you need multiple
> threads. Also I am wondering if the threading stuff is being taken
> care by gr-ieee 802.11 package or GNU Radio. Because I coudn't find
> any threading related stuff in the mentioned
> package. 
> 
> In my code, I am using pthreads, there is a thread pool which creates
> 50 threads for receiver. But it crashes and goes out of sync for
> almost 60% of the times. I was wondering if I can get some clue to
> deal with real time decoding from users. 
> 

Sorry for being late to the game...

I've done a fair amount of work in this area. You can use multi-
threading and OpenMP in GNURadio but you have to be careful. Note that
I haven't had a chance to play with GCC7/OpenACC, yet.

This is from memory.

The first rule of thumb is NOT use more than 5/8 of the available
cores/threads. You are competing out-of-band against the processing
power and resources managed by the GNURadio run-time with the likely
result of dropped samples and an unresponsive, and even locked up, UI
and potentially problems at the operating system level, such as the
queuing and dropping of USB packets.

The second rule of thumb is you cannot do anything with run-time
resources outside the GNURadio threading framework. For example, the
GNURadio run-time places a giant lock on an object to block the
object's thread for accessing shared data structures. If you are
operating outside that lock mechanism the outcome is predictable.

However, if you have data structures that are shared between the
block's thread and your custom threads then you need to put a mutex
around those structures. To simplify, I had ported the Google GCL
libraries (with modifications, of course). They work but you can also
do the same using the C++ standard library mutex/etc primitives.
However, you have to manage the amount of time a lock blocks the run-
time thread. Seconds are generally bad.

Third, make sure the memory management and system calls are thread
safe. Obviously bad things will happen if they are not.

Fourth, file and socket I/O is probably a bad thing to do. That has to
happen within the block and even then it should be discouraged.

One of my more complex blocks worked this way from a threading
perspective:

 GNU Block -> Load samples onto a protected queue.
  Thread #1 -> Qualify samples against the first set of 
               criteria then load a qualified sample set 
               onto a second protected queue. Very busy.
  Thread #2 -> More qualification criteria. If a sample 
               set remains qualified, load it on another 
               protected queue. Less busy but busy 
               nonetheless.
  Thread #4 -> Similar qualifications. This time add math. 
               Similar result.
  Thread #5 -> Very minor work. If successful, load 
               the samples onto a queue that will be 
               picked up by the block thread.
 GNU Block -> If there is something ready, then forward it 
              to the next block.

My GNU block was fairly simple:

 if( anything on the input stream )
   pass it to customized threading 
 if( anything ready from custom threading )
   pass it to the next block

To avoid many copy operations I use the shared_ptr class. That DOES NOT
mean I didn't have multiple sample copies in my memory structures.

This process allowed me to use the maximum amount of processor cores to
work against fairly fast sampling with the caveat that
mutexes/containers/threads themselves have overhead however I could
amortize those costs while minimizing the impact against the run-time.

I have also used OpenMP in many places with the same caveat of NOT
overusing cores/threads.

I have done somewhat similar threading/OpenMP in other applications.
Well, after lessons learned. Big :)

You have to decide what you can realistically do against the number of
available cores, the processor speed, the amount of memory, etc. You
also do not know the load of other run-time blocks that your custom
threading is competing against. Code analysis and modeling may be
necessary.

Finally, I haven't had any problems mixing C++ 11/14 compiled code with
GNURadio however I strongly suggest you use the same compiler. On this
subject, mixing compilers is generally a bad thing to do whether it is
something like GCC-4 verses GCC-6 or CLang verses GCC. 



> 

> Regards
> Sumit 
> 
> 
> 
> --
> View this message in context: http://gnuradio.4.n7.nabble.com/gr-
> ieee-802-11-and-threads-for-real-time-tp61872.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



reply via email to

[Prev in Thread] Current Thread [Next in Thread]