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
