The overflow warning occurs when the period parameter is set to 1 for a
pdu_length of 100. The rate is around 1.9e6. I am sorry but I didn't get
the point of this exercise. Were you trying to figure out the optimal value
of the buffer size ?



Abhinav PS  Jadon
2012122
Electronics and Communication Engineering Undergraduate
IIIT - Delhi
IASc Summer Research Fellow 2015
*E*: jadonabhi...@gmail.com
*M*: +919650936845



On Thu, Mar 31, 2016 at 1:51 PM, Marcus Müller <marcus.muel...@ettus.com>
wrote:

> What probably would be even more insightful is if you could enable
> ctrlport and add a ctrlport monitor to your flow graph; that way we could
> see whether the output buffer of OFDM mapper is constantly full.
>
> 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
> *M*: +919650936845
>
>
>
> On Wed, Mar 30, 2016 at 3:48 AM, Marcus Müller <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>jadonabhi...@gmail.com
>> *M*: +919650936845
>>
>>
>>
>> On Wed, Mar 30, 2016 at 1:27 AM, Alexander Levedahl <
>> <alexanderleved...@gmail.com>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>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>jadonabhi...@gmail.com
>>>> *M*: +919650936845
>>>>
>>>>
>>>>
>>>> On Wed, Mar 30, 2016 at 12:42 AM, Alexander Levedahl <
>>>> <alexanderleved...@gmail.com>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>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>jadonabhi...@gmail.com
>>>>>> *M*: +919650936845
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 30, 2016 at 12:17 AM, Marcus Müller <
>>>>>> <marcus.muel...@ettus.com>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>Discuss-gnuradio@gnu.org
>>>>>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>>>>>> 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