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
