|
| From: | Dennis Glatting |
| Subject: | [Discuss-gnuradio] OMP Data. GNURadio overhead? |
| Date: | Fri, 14 Aug 2015 11:03:24 -0700 |
Sorry for the HTML... I have been done some work applying OpenMP to GNURadio and collected some data. This data was collected WITHOUT GNURadio overhead. Specifically, I interfaced directly with my detector passing 30 seconds (30 seconds * 10msps) of data in a buffer (i.e., I allocated and filled gr_vector_const_void_star, etc.) and calculated the performance at different sensitivities. Herein lies one problem. When applying OpenMP against a buffer there has to be enough data to make it worth while but GNURadio buffers are fairly small. I don't see a reasonable way to increase buffer sizes for a single source->block without modifying the constant in flat_flowgraph.cc which has the side effect of the default size for all buffers. Yes? I am looking for a way to measure GNURadio overhead. There is a certain amount of overhead depending on the number of blocks, set() functions, GUI Sinks, etc. and I'd like to know what that overhead is. Ideas? One thought is to set a hardware pin low in the source block and set it high in the detector block then measuring with a scope. The problem is these pins often incur kernel overhead by opening something in /dev, writing a string, then closing the device and waiting for the kernel to get around to actually toggling the pin. Measurements showed this is wildly unpredictable. Another option is to toggle a ping on an SDR but the same problem exists with additional USB transaction delays. Anyway, in the data below a "signal" buffer is defined as ~1200 samples (i.e., MAXimum message size), or 2x1200=2400 complex number "chunks". I found 2xMAX a reasonable value because it is within a reasonable buffer amount from GNURadio with my alteration to flat_flowgraph.cc. The OpenMP code really looks like this: #pragma omp parallel for num_threads(ncpu),schedule(dynamic,1) \ if( work_list.size() > 1 ) for( size_t i = 0; i < work_list.size(); ++i ) { do work... } Pretty simple. That said, unless GNURadio can provide a selective and reasonably large amount of samples to process then the value of applying OpenMP is probably moot. Below, the term "sensitivity" is a bit of a misnomer because as sensitivity increases signal rejection increases; but the text is what it is. More specifically, there are roughly twelves sets of criteria that need to be met before signal presence is declared. Some of those criteria involve std::log10() and std::pow(10.0,x) operations but interestingly those math operations are a very small amount of the detection effort (1.02% worst case). The numbers in the first block below is the rate in samples/second I can process samples. For example, "Baseline" "45.0" is "1,662,796" samples per second. From an OpenMP perspective, I have eight cores but limited the effort to five with the idea GNURadio overhead and other blocks have three cores to do their thing, worst case. OpenMP gave me a >300% performance gain in "OMP 5core,2xMAX) but the theoretical gain is 400%. Not perfect but I'll take it. What these numbers tell me is OpenMP can have significant value in the context of GNURadio. My code was run on an AMD 9590 at 4.7GHz, 5GHz boost -- my development platform. For reasons, I also ran it on a CubieBoard4 (ARM architecture). I should also mention I have seen NO side effects of running OpenMP within GNURadio other than considerable amusement.
|
| [Prev in Thread] | Current Thread | [Next in Thread] |