Just for clarification: use a new flow graph/disable everything but
these blocks; the point is to test how much we produce with that.

On 31.03.2016 10:13, Marcus Müller wrote:
> Hi Abhinav,
>
> On 31.03.2016 02:42, Abhinav Jadon wrote:
>> I ran the volk_profile just after the installation so that is not an
>> issue i guess. Also, I played around with the parameters of the
>> message strobe ( the period parameter), it did have an effect on the
>> underruns and the async message buffer overflow warning. Low values
>> of the period parameter prompted async message overflow warnings and
>> high values of the period parameter prompted underruns ( a lot of
>> them) .
> Sooo, ok.
> My head was stuck on UHD/the USRP being a problem here, but:
> "asynchronous message buffer overflowing, dropping message"
> is a GNU Radio warning!
> So what happens here is that messages are sent to a block that's not
> processing them fast enough, and at some point, the message buffer
> just gets too big.
> There's basically two candidates for this, because your message
> passing chain is:
>
> Message Strobe-> OFDM MAC->OFDM Mapper(->stream)
>
> so my guess is that this happens at the OFDM Mapper, because that is
> the block whose message processing rate is limited by the amount of
> samples it can produce, which is defined by how fast the USRP sink
> consumes those, in the end.
>
> Quick test: Take the "Message Strobe -> OFDM MAC -> OFDM Mapper" and
> just attach a "->Probe Rate->Message Debug".
> How many items per second do your generate with the settings you use
> when you get a lot of the "async mess. buff. overflow" warnings?"
>
> Best regards,
> Marcus
>> What I dont understand is if the USRP is in the burst mode, why does
>> the period parameter change things ? If the USRP is set to sample
>> rate of 20e6, then it expects period*sample_rate samples to be
>> supplied to it. That requires to change the length of the message again. 
>> Whats wrong here ? 
>>
>> Regards
>>
>> Abhinav PS  Jadon
>> 2012122
>> Electronics and Communication Engineering Undergraduate
>> IIIT - Delhi
>> IASc Summer Research Fellow 2015
>> *E*: jadonabhi...@gmail.com <mailto:jadonabhi...@gmail.com>
>> *M*: +919650936845
>>
>>
>>
>> On Wed, Mar 30, 2016 at 3:48 AM, Marcus Müller
>> <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>> wrote:
>>
>>     Did you run volk_profile? That one tries out all volk kernels,
>>     and notes down which one works best on your PC, so they'll be
>>     used automatically the next time. Maybe that increases performance!
>>
>>
>>     On 29.03.2016 22:24, Abhinav Jadon wrote:
>>>     gcc version is 4.8.4
>>>     cpuinfo output :
>>>     flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
>>>     pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht
>>>     tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon
>>>     pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu
>>>     pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma
>>>     cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt
>>>     tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida
>>>     arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
>>>     fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt
>>>
>>>     Since sse4_2 figures in the list and all the SIMD architectures
>>>     are backward compatible, i think its right to say that sse4_2 is
>>>     the answer we are looking for ?
>>>
>>>     Also ,
>>>     gnuradio version - '3.7.9.1'
>>>     volk version - is in latest version as I pulled it from github
>>>     yesterday.
>>>
>>>     Abhinav PS  Jadon
>>>     2012122
>>>     Electronics and Communication Engineering Undergraduate
>>>     IIIT - Delhi
>>>     IASc Summer Research Fellow 2015
>>>     *E*: jadonabhi...@gmail.com
>>>     *M*: +919650936845
>>>
>>>
>>>
>>>     On Wed, Mar 30, 2016 at 1:27 AM, Alexander Levedahl
>>>     <alexanderleved...@gmail.com> wrote:
>>>
>>>         Abhinav,
>>>
>>>         I am not certain what to make of the asynch message buffer
>>>         overflowing.
>>>
>>>         The __SSE2_MATH__, __SSE_MATH__, __SSE2__, __SSE__ defines
>>>         are the SIMD preprocessor defines.  Can you run gcc
>>>         --version and do cat /proc/cpuinfo | grep flags?  The former
>>>         will indicate the gcc version number.  The latter will
>>>         indicate what SIMD instructions the processor actually
>>>         supports.  Also do you know what version of VOLK and
>>>         gnuradio you have?
>>>
>>>         On Tue, Mar 29, 2016 at 3:50 PM, Abhinav Jadon
>>>         <abhinav12...@iiitd.ac.in> wrote:
>>>
>>>             Hi Alex ,
>>>             The output in the console was all 'U's before I disabled
>>>             the WX/GUI blocks.
>>>             Now, it seems to run fine initially before throwing this
>>>             message :
>>>
>>>                 "WARN: asynchronous message buffer overflowing,
>>>                 dropping message"
>>>
>>>
>>>
>>>
>>>             The output of gcc -dM -E - < /dev/null | grep -e "SE" -e
>>>             "AVX" was :
>>>             #define __USER_LABEL_PREFIX__
>>>             #define __SSE2_MATH__ 1
>>>             #define __ATOMIC_HLE_RELEASE 131072
>>>             #define __SSE_MATH__ 1
>>>             #define __SSE2__ 1
>>>             #define __GCC_ATOMIC_TEST_AND_SET_TRUEVAL 1
>>>             #define __SSE__ 1
>>>             #define __ATOMIC_SEQ_CST 5
>>>             #define __ATOMIC_RELEASE 3
>>>
>>>
>>>             I have an idea about what SIMD is, although I could not
>>>             find any SIMD preprocessor defines.
>>>             Am I missing something here?
>>>
>>>             Abhinav PS  Jadon
>>>             2012122
>>>             Electronics and Communication Engineering Undergraduate
>>>             IIIT - Delhi
>>>             IASc Summer Research Fellow 2015
>>>             *E*: jadonabhi...@gmail.com
>>>             *M*: +919650936845 <tel:%2B919650936845>
>>>
>>>
>>>
>>>             On Wed, Mar 30, 2016 at 12:42 AM, Alexander Levedahl
>>>             <alexanderleved...@gmail.com> wrote:
>>>
>>>                 Abhinav,
>>>
>>>                 When you run the flowgraph, can you look at system
>>>                 monitor?  This will give some indication whether the
>>>                 problem is that all the cores are pegged or if RAM
>>>                 is filling up. 
>>>                 A couple of other things to look at:
>>>                 1) Is there any text being printed to the console?
>>>                 2) What happens if you disable the GUI blocks? 
>>>                 Simple method would be to open the flowgraph select
>>>                 the blocks that have GUIs associated with them, hit
>>>                 D (for disable) and then run the graph.
>>>                 3) Would you happen to know which SIMD instructions
>>>                 it is using?  Run
>>>                 gcc -dM -E - < /dev/null | grep -e "SE" -e "AVX"
>>>                 The gcc -dM -E will print out the preprocessor
>>>                 defines. The - < /dev/null forces gcc to exit
>>>                 immediately.  The "SE" flag filters the preprocessor
>>>                 defines for any of the SSEE SIMD instructions; the
>>>                 "AVX" flag filters for the AVX SIMD instructions. 
>>>
>>>
>>>                 Sometimes the processor supports SIMD instructions
>>>                 that the compiler (due to age) does not support.
>>>
>>>                 Alex
>>>
>>>
>>>                 On Tue, Mar 29, 2016 at 2:57 PM, Marcus Müller
>>>                 <marcus.muel...@ettus.com> wrote:
>>>
>>>                     That's pretty much impossible to say.
>>>                     My prime suspect would be the WX Gui
>>>                     visualization sink. Really, a couple of 64 FFTs
>>>                     aren't that terrible performance-wise.
>>>
>>>
>>>                     On 29.03.2016 20:53, Abhinav Jadon wrote:
>>>>                     Marcus,
>>>>                     Thanks for all the help.
>>>>                     But Is my system underpowered ?
>>>>                     Also, I just observed that if I bunch few
>>>>                     blocks in the tx flowgraph in a similar way as
>>>>                     phy_hier block in the wifi_loopback flowgraph,
>>>>                     I dont receive any more underruns.
>>>>
>>>>
>>>>                     Regards
>>>>
>>>>                     Abhinav PS  Jadon
>>>>                     2012122
>>>>                     Electronics and Communication Engineering
>>>>                     Undergraduate
>>>>                     IIIT - Delhi
>>>>                     IASc Summer Research Fellow 2015
>>>>                     *E*: jadonabhi...@gmail.com
>>>>                     *M*: +919650936845 <tel:%2B919650936845>
>>>>
>>>>
>>>>
>>>>                     On Wed, Mar 30, 2016 at 12:17 AM, Marcus Müller
>>>>                     <marcus.muel...@ettus.com> wrote:
>>>>
>>>>                         When you set the length tag field in the
>>>>                         USRP sink, it starts looking for that
>>>>                         stream tag, which contains number of
>>>>                         samples in the starting burst.
>>>>
>>>>                         Technically, that starts a uhd::tx_streamer
>>>>                         for a finite number of samples, which means
>>>>                         different things for different hardware.
>>>>
>>>>                         Best regards,
>>>>                         Marcus
>>>>
>>>>
>>>>                         On 29.03.2016 20:44, Abhinav Jadon wrote:
>>>>>                         Hi Marcus,
>>>>>                         I am working on a Core i7 8GB system, I
>>>>>                         dont know if its underpowered, if it is I
>>>>>                         have access to another Corei5 16 GB station. 
>>>>>                         I know this is going to sound dumb but,
>>>>>                         how does the USRP sink go into burst mode,
>>>>>                         I was under the impression that USRP could
>>>>>                         only transmit data continuously.  Do you
>>>>>                         toggle the RF frontend using a switch on
>>>>>                         receiving a message ?
>>>>>
>>>>>
>>>>>
>>>>>                         Regards
>>>>>                         Abhinav PS  Jadon
>>>>>
>>>>
>>>>
>>>
>>>
>>>                     _______________________________________________
>>>                     Discuss-gnuradio mailing list
>>>                     Discuss-gnuradio@gnu.org
>>>                     https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>>
>>>
>>>
>>
>>
>

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to