That's mightily interesting! I feel like we should be doing bug reports, but I'm not sure where.
On 26.06.2017 06:42, Cor Legemaat wrote: > Found it: > > Created an C++ app that called that function with the same parameter > values as with python for this flow graph. Witch I was able to debug > normally. > > In window.cc line 265, with i = ntaps - 1, temp = > 1.0000000000000000002 that cause sqrt (0) witch return "-nan" on the > next line and screw all the rest of the calculations. > > This only happens when compiled with "CFLAGS=-march=native -O2", if I > don't specify the march it's working correctly. The function is called > on my system with taps=787 and beta = 7. > > Regards: > Cor > > On Wed, 2017-06-21 at 15:13 +0200, Cor Legemaat wrote: >> Hi: >> >> Sorry for the late replay... The intel pc call filter.firdes.low_pass >> with the same values but return 768 proper float values, not like the >> <nan>'s on the AMD pc. >> >> Tried to debug with "nemiver /usr/bin/python2.7 -u >> <path>/fm_receiver.py" and the breakpoint at firdes.cc line 100 witch >> get triggered and I can read the function parameters but when I try >> to step true the function it jumps to the assembly of pthread. If I >> put more breakpoints in firdes.cc I get back to the function but cant >> read any variables any more. Also tried exporting "export >> GR_SCHEDULER=STS" but the same symptoms. >> >> Don't know if Ubuntu will trigger the bug it's probably compiled more >> generic... >> >> Regards: >> Cor >> >> On Wed, 2017-06-07 at 04:26 -0400, Anon Lister wrote: >>> I have an AMD system with the same chip running Ubuntu 16.xx. I can >>> probably try to duplicate this weekend, if Cor doesn't get to it, as >>> another data point. >>> >>> On Jun 5, 2017 3:14 PM, "Marcus Müller" <marcus.muel...@ettus.com >>> <mailto:marcus.muel...@ettus.com>> wrote: >>> >>> Hi Cor, >>> >>> Excuse the language, but faaaark. Ok, looks like we have a bug >>> in low_pass. Or in GCC. Or SWIG (which does the python-wrapping >>> of the code in firdes.cc). yay. >>> >>> So, let's narrow this down: on intel and amd64, same number of >>> taps, right? >>> >>> Then: If I asked you to use GDB to verify the C++ low_pass >>> function in gr::filter::firdes::low_pass actually returned the >>> right float values, would you feel that, with a few hints, be >>> able to do that? >>> >>> Best regards, >>> >>> Marcus >>> >>> >>> On 01.06.2017 07:20, Cor Legemaat wrote: >>>> Hi: >>>> >>>> filter.firdes.low_pass get called with: >>>> * fractional_bw = 0.4 >>>> * trans_width = 0.1 >>>> * mid_transition_band = 0.45 >>>> * interpolation = 24 >>>> >>>> But return: (nan, <788 times nan>) >>>> >>>> Regards: >>>> Cor >>>> >>>> On Tue, 2017-05-30 at 00:06 +0200, Marcus Müller wrote: >>>>> Hi Cor, >>>>>> * When using 1 as "taps" there is output. >>>>> Aha!! >>>>> So, here's the thing: something might be going wrong in the python >>>>> code that sets up the taps automatically if you don't set them >>>>> explicitly. >>>>> Maybe you can figure out where things go wrong; the interesting part >>>>> (maybe add some `print`s here?) from [1]: >>>>> >>>>> # If we don't have user-provided taps, reduce the interp and >>>>> # decim values by the GCD (if there is one) and then define >>>>> # the taps from these new values. >>>>> if taps is None: >>>>> interpolation = interpolation // d >>>>> decimation = decimation // d >>>>> taps = design_filter(interpolation, decimation, >>>>> fractional_bw) >>>>> >>>>> and >>>>> >>>>> >>>>> def design_filter(interpolation, decimation, fractional_bw): >>>>> """ >>>>> Given the interpolation rate, decimation rate and a fractional >>>>> bandwidth, >>>>> design a set of taps. >>>>> >>>>> Args: >>>>> interpolation: interpolation factor (integer > 0) >>>>> decimation: decimation factor (integer > 0) >>>>> fractional_bw: fractional bandwidth in (0, 0.5) 0.4 works >>>>> well. (float) >>>>> Returns: >>>>> : sequence of numbers >>>>> """ >>>>> >>>>> if fractional_bw >= 0.5 or fractional_bw <= 0: >>>>> raise ValueError, "Invalid fractional_bandwidth, must be in >>>>> (0, 0.5)" >>>>> >>>>> beta = 7.0 >>>>> halfband = 0.5 >>>>> rate = float(interpolation)/float(decimation) >>>>> if(rate >= 1.0): >>>>> trans_width = halfband - fractional_bw >>>>> mid_transition_band = halfband - trans_width/2.0 >>>>> else: >>>>> trans_width = rate*(halfband - fractional_bw) >>>>> mid_transition_band = rate*halfband - trans_width/2.0 >>>>> >>>>> taps = filter.firdes.low_pass(interpolation, >>>>> # gain >>>>> interpolation, >>>>> # Fs >>>>> mid_transition_band, >>>>> # trans mid point >>>>> trans_width, >>>>> # transition width >>>>> filter.firdes.WIN_KAISER, >>>>> beta) >>>>> # beta >>>>> >>>>> return taps >>>>> >>>>> >>>>> >>>>> Best regards, >>>>> Marcus >>>>> >>>>> [1] https://github.com/gnuradio/gnuradio/blob/master/gr-filter/python >>>>> <https://github.com/gnuradio/gnuradio/blob/master/gr-filter/python> >>>>> /filter/rational_resampler.py >>>>> >>>>> On 29.05.2017 19:01, Cor Legemaat wrote: >>>>>> Hi: >>>>>> >>>>>> * The only warning is about the thread priority but that's on >>>>>> both. >>>>>> * Type "Complex->Complex (Complex Taps)" >>>>>> * When using 1 as "taps" there is output. >>>>>> >>>>>> I can open it in Nemiver if I know where to put the break point... >>>>>> >>>>>> Regards: >>>>>> Cor >>>>>> >>>>>> On Mon, 2017-05-29 at 11:36 +0200, Marcus Müller wrote: >>>>>>> Hi Cor, >>>>>>> that's kind of surprising¹. My first bet is that your AMD system >>>>>>> is >>>>>>> missing some dependency that the intel system has, so that >>>>>>> something >>>>>>> goes wrong during build. But then again, you shouldn't be seeing >>>>>>> the >>>>>>> rational resampler block at all in that case. Let's head straight >>>>>>> to >>>>>>> debugging: >>>>>>> * Do you get any warning/console output during the execution of >>>>>>> that >>>>>>> flow graph? >>>>>>> * Which is the input/output type (float or complex, orange or >>>>>>> blue >>>>>>> connector in GRC, if using that) >>>>>>> * If in GRC: when explicitly using [1,] as "taps", do you get >>>>>>> output? >>>>>>> Best regards, >>>>>>> Marcus >>>>>>> >>>>>>> ¹ "wat?!" >>>>>>> >>>>>>> On 29.05.2017 06:35, Cor Legemaat wrote: >>>>>>>> Hi: >>>>>>>> >>>>>>>> I have 2 different hardware setup's with funtoo/gentoo and >>>>>>>> gnuradio >>>>>>>> installed. On the Intel system the "Rational Resampler" is >>>>>>>> working >>>>>>>> correctly but on the AMD system there is no output. This is on >>>>>>>> a >>>>>>>> flow >>>>>>>> graph for an basic wide band fm receiver based on the USPR >>>>>>>> 10min fm >>>>>>>> receiver tutorial. >>>>>>>> >>>>>>>> AMD system: >>>>>>>> * AMD FX(tm)-8150 Eight-Core Processor >>>>>>>> * CPU_FLAGS_X86="aes avx fma4 mmx mmxext popcnt sse sse2 sse3 >>>>>>>> sse4_1 sse4_2 sse4a ssse3 xop" >>>>>>>> >>>>>>>> Intel system: >>>>>>>> * Intel(R) Core(TM) i5-2430M CPU @ 2.40GHz >>>>>>>> * CPU_FLAGS_X86="aes avx mmx mmxext popcnt sse sse2 sse3 >>>>>>>> sse4_1 >>>>>>>> sse4_2 >>>>>>>> ssse3" >>>>>>>> >>>>>>>> Tried with different versions of GNURadio and gcc but the same >>>>>>>> symptoms, both systems is compiled with CFLAGS="-march=native >>>>>>>> -O2 >>>>>>>> -pipe". At the moment it is gcc:6.3.0 and net- >>>>>>>> wireless/gnuradio- >>>>>>>> 3.7.11:0/3.7.11 USE="alsa analog atsc audio channels digital >>>>>>>> doc >>>>>>>> dtv >>>>>>>> examples fec filter grc noaa pager performance-counters >>>>>>>> portaudio >>>>>>>> qt4 >>>>>>>> uhd utils vocoder wavelet wxwidgets zeromq -fcd -jack -log -oss >>>>>>>> -sdl {- >>>>>>>> test} -trellis" PYTHON_TARGETS="python2_7" >>>>>>>> >>>>>>>> Where do I start to search? >>>>>>>> >>>>>>>> Regards: >>>>>>>> Cor >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Discuss-gnuradio mailing list >>>>>>>> Discuss-gnuradio@gnu.org <mailto: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 <mailto: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 <mailto: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 <mailto: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 >>> <mailto: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 <mailto:Discuss-gnuradio@gnu.org> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> _______________________________________________ >> 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
