> To reduce the computation load of the processor, I tried two methods: > 1) modify the gr.quadrature_demod_cf block, replace some multiplication > operations with volk-based operations (gr.multiply and gr.multiply_const > modules in gr_blocks);
I like it. Make sure to contribute patches like that back. :-) > 2) use complex_int16 type instead of complex_float32 at uhd interfaces > and modulation / demodulation blocks. > > But I got unexpected results after the changes. If I adopt method 1), > the amount of correctly demodulated data is roughly the same as when > using the original demodulation block. And for method 2), the result is > even worse - less data is correctly demodulated. > I wouldnt expect it to be worse in general. How did you implement it? Did you combine the float to short conversion into the processing of another block? Or did you add an extra block of conversion from float to short, because the extra conversion would definitely make things worse. Also, you may consider timing a particular operation as a performance metric, rather than counting the number of demodulated packets. > Could someone please tell me if I did something wrong, or there are > other solutions to this overflow-at-high-sample-rate problem? > > On e100, I burned the latest console file system, use > UHD_003.004.000-6795022, and Josh's next branch of GNU radio, > uhd setup: center frequency 2.416 GHz, sample rate 4M. > BTW, I just updated my next branch, in which I pulled into it the volk-ified adder, multipliers. So if any of the code you are using, includes a gr.add, add const, mult, etc for floating point or float complex; you will get the benefit without any code change. > BTW, it took almost twice the amount of time to build both uhd and GNU > radio after burning the latest console file system, and the > initialization process of uhd (when device information is printed out) Where did you get the rootfs? When I hear "console" image, I think you might be using something very very old. Perhaps you just downgraded by accident. You can find the latest stuff here: http://code.ettus.com/redmine/ettus/projects/usrpe1xx/wiki/FAQ#How-do-I-create-re-create-E1xx-SD-Card-Images http://files.ettus.com/e1xx_images/e1xx-002/ > took a lot longer time than before as well. But what I concerned more is > that much fewer packets could be received, compared with another e100 > which has the same flow graph setup but installed previous versions of > tools: file system, UHD_003.004.000-1a25e48, GNU radio 3.5.0. Could it Can you isolate some of the changes? Perhaps keep the console image constant, or version or maybe uhd; basically to see in which package, uhd, gnuradio, rootfs, gcc there was this performance regression? I cant recall something specific in gnuradio or uhd that would have changed performance. There is honestly not significant e100 changes between 1a25e48 and current master. -Josh _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
