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 <mailto:jadonabhi...@gmail.com> >> *M*: +919650936845 >> >> >> >> On Wed, Mar 30, 2016 at 1:27 AM, Alexander Levedahl >> <alexanderleved...@gmail.com >> <mailto: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 <mailto: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 <mailto:jadonabhi...@gmail.com> >> *M*: +919650936845 <tel:%2B919650936845> >> >> >> >> On Wed, Mar 30, 2016 at 12:42 AM, Alexander Levedahl >> <alexanderleved...@gmail.com >> <mailto: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 >> <mailto: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 >>> <mailto:jadonabhi...@gmail.com> >>> *M*: +919650936845 <tel:%2B919650936845> >>> >>> >>> >>> On Wed, Mar 30, 2016 at 12:17 AM, Marcus Müller >>> <marcus.muel...@ettus.com >>> <mailto: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 >> <mailto: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
