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*: [email protected] *M*: +919650936845 On Wed, Mar 30, 2016 at 12:42 AM, Alexander Levedahl < [email protected]> 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 <[email protected]> > 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*: [email protected] >> *M*: +919650936845 >> >> >> >> On Wed, Mar 30, 2016 at 12:17 AM, Marcus Müller <[email protected] >> > 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 >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
