Re: [Discuss-gnuradio] Non-deterministic behavior in GNU Radio

[Andrej Rode]

Hi all, 

I just created an issue for that in the volk GitHub repository: 
https://github.com/gnuradio/volk/issues/202

The normalized error seemed to be in the ~1e-8 range (errors in volk are
normalized to the amplitude of the result in question)
Thus it passes the default error threshold of 1e-6. 

Marcus pointed out offline that some of the intrinsics might even have a
better precision compared to the generic implementation.

Cheers
Andrej

On Wed, Oct 03, 2018 at 04:57:32PM -0700, Ron Economos wrote:
> It depends on which box I look at.
> 
> 1) volk_32fc_x2_divide_32fc a_avx u_sse3
> 
> 2) volk_32fc_x2_divide_32fc a_avx u_avx
> 
> Ron
> 
> On 10/03/2018 08:05 AM, Müller, Marcus (CEL) wrote:
> > Well, I'd be willing to call that a bug, all in all:
> >
> > Though I totally get the "machine accuracy" argument, I'd at least
> > expect the same results when running the same program twice, on the
> > same machine.
> >
> > Now, I'm an author of one of the 32fc_x2_divide_32fc implementations;
> > I'd like to know what I can do to fix this. Ron, what was the machine
> > that volk_profile picked for you?
> >
> > By the way, just as for the float/char (and other ints) conversion
> > kernels, it's not inherently obvious who's right or wrong, the
> > optimized or the generic impl. So, we should be analyzing which values
> > led to the differing result.
> >
> > Best regards,
> > Marcus
> >
> > On Wed, 2018-10-03 at 06:52 -0700, Ron Economos wrote:
> >> That's the problem. If a set_output_multiple(4) in added to the
> >> constructor in divide_cc_impl.cc, it solves the issue.
> >>
> >> Ron
> >>
> >> On 10/03/2018 06:42 AM, Ron Economos wrote:
> >>> Well, I guess it's not really a bug. Most likely it has to do with the
> >>> accuracy difference between the x86 intrinsics and the C library. If
> >>> you look at the code in volk_32fc_x2_divide_32fc.h, the remaining
> >>> points that are not a multiple of four are calculated with the C
> >>> library. If the points from one run that are calculated with the C
> >>> library line up with points calculated with intrinsics in the next
> >>> run, there can be a mismatch.
> >>>
> >>> Ron
> >>>
> >>> On 10/03/2018 06:27 AM, Ron Economos wrote:
> >>>> It's a VOLK bug. Go into ~/.volk/volk_profile and change the
> >>>> volk_32fc_x2_divide_32fc line to generic. That fixes the issue here.
> >>>>
> >>>> Ron
> >>>>
> >>>>
> >>>> On 10/03/2018 05:46 AM, Piotr Krysik wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> I simplified the flowgraph a bit and prepared a script that runs it
> >>>>> twice and compares the results.
> >>>>>
> >>>>> https://imgur.com/a/CSjOeLc
> >>>>>
> >>>>> In short something is wrong indeed.
> >>>>> Almost after every run of the script I get results with differences.
> >>>>>
> >>>>> I tested it on GNU Radio  3.7.12.0, I'm compiling the most fresh
> >>>>> version
> >>>>> now.
> >>>>>
> >>>>> Best Regards,
> >>>>> Piotr Krysik
> >>>>>
> >>>>> W dniu 03.10.2018 o 06:55, Reiichiro Nakano pisze:
> >>>>>> Here's an updated flowgraph where you don't need a separate file
> >>>>>> source. Just run the flowgraph twice for a few seconds each. You'll
> >>>>>> likely get different file sizes but `cmp` doesn't care, it'll still
> >>>>>> show the first differing byte which should still prove the bug exists.
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-- 
Andrej Rode
GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA

signature.asc
Description: Digital signature