> Why do we have a normalized error instead of a absolute error threshold
> at all?
Welll because this is float ... only relative errors matter.
If you have a signal between -1e6 and 1e6 , then an error or 0.1 is
really not all that important. OTOH if your signal is -1 .. +1, then
an error or 0
On Tue, Oct 09, 2018 at 01:25:01PM +0200, Sylvain Munaut wrote:
> I'm starting to wonder if having different precision version of the
> kernels wouldn't make sense ...
>
Totally makes sense.
For the case of approximation it might be sufficient to document the
worst case error and measure the abs
I'm starting to wonder if having different precision version of the
kernels wouldn't make sense ...
TBH most of the time I don't care that much about precision because my
input data is noisy and the 0.1 dB difference doesn't matter, I much
prefer to be _fast_.
Especially for something like log2 t
Another kernel with a lot of variying precision is the log2
implementation since it's currently a polynomial approximation with a
6-th degree polynomial.
The glibc implementation uses a 14-th degree polynomial to approximate
log2 which turns out to have a maximum error of 2**-58.45.
Probably the
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.
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
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 c
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
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 f
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
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
I'm not using those deprecated blocks.
Anyway, I dug deeper and found the block that was causing the indeterminate
behavior. It is the complex "Divide" block! Here's a minimum reproducible
flowgraph. You'll have to adjust the file source to use some IQ stream you
may have lying around. Sorry about
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.
On Wed, Oct 3, 2018 at 1:5
Are you perchance using the modulator and demodulator blocks from the
"Deprecated" category?
Best regards,
Marcus
On Tue, 2018-10-02 at 19:34 +0900, Reiichiro Nakano wrote:
> Interesting. Thanks for the response. I also have a bunch of message passing
> going on. Do you think it could be droppe
Interesting. Thanks for the response. I also have a bunch of message
passing going on. Do you think it could be dropped messages? I seem to
remember reading that PMT ports aren't back pressured like the streaming
ports. What happens when a queue fills up and the block can't catch up?
Anyway, what
Hi,
> Unfortunately, there were no further replies to that thread but I did see
> that my same question "pops up every once in a while". Anyway, my specific
> problem is I'm trying to QPSK demodulate + RS decode a 2MS/s, 1Mbps bit rate,
> 10GB IQ file. This works fine, but I'm getting a differe
Hey everyone, I saw an e-mail exchange a while back regarding an issue
similar to the one I'm facing right now. Here's the link to the archive:
https://lists.gnu.org/archive/html/discuss-gnuradio/2013-01/msg00481.html.
Unfortunately, there were no further replies to that thread but I did see
that
Hi Vanessa,
a question like this pops up every once in a while. Is your dat file
pretty large? This would fit with what others have been reporting.
Is there any way you could provide an example of something that is
failing?
Also, have you tried reducing the throttle to something pretty
ridiculou
This might be easier to get help with if you sent some code or a GRC
file. Or we can go with 21 questions in which case I have my own :-)
Are you getting any over/under flows (O's or U's being printed to
console) when you run the flowgraph? Any output at all?
On Thu, Jan 31, 2013 at 1:31 AM, Vane
No, I am not.
On Tue, Jan 29, 2013 at 4:01 PM, Marcus D. Leech wrote:
> On 01/29/2013 04:47 AM, Vanessa Gardellin wrote:
>>
>> Yes, we are using a throttle but when we execute the same python file
>> we obtain always different outcomes.
>> We would like to have repeatable experiments.
>> Any tips
On 01/29/2013 04:47 AM, Vanessa Gardellin wrote:
Yes, we are using a throttle but when we execute the same python file
we obtain always different outcomes.
We would like to have repeatable experiments.
Any tips?
Thank you
Vanessa
Are you using a channel model in the middle of your simulation?
We do not have any random generator in the code that we wrote.
We generate 100 packets always of the same size and containing all "a".
Could it be something that depends on the scheduler or on how threads
are handled?
On Tue, Jan 29, 2013 at 12:09 PM, Mike Jameson wrote:
> Hi Vanessa,
>
> If you
Hi Vanessa,
If you are using a random number generator, remember to save and re-use the
same 'seed' and also to reset it to the beginning of each run.
Mike
M0MIK
On 29 January 2013 09:47, Vanessa Gardellin wrote:
> Yes, we are using a throttle but when we execute the same python file
> we obtai
Yes, we are using a throttle but when we execute the same python file
we obtain always different outcomes.
We would like to have repeatable experiments.
Any tips?
Thank you
Vanessa
On Mon, Jan 28, 2013 at 5:46 PM, Mike Jameson wrote:
> Hi,
>
> Make sure you are using a 'throttle' block. Have a l
Hi,
Make sure you are using a 'throttle' block. Have a look at the following:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Simulations
Mike
M0MIK
On 28 January 2013 16:40, Vanessa Gardellin wrote:
> Dear all,
> we are experiencing an undesired random behavior when we run an
> offline OF
Dear all,
we are experiencing an undesired random behavior when we run an
offline OFDM flow graph.
Specifically, we store a transmitted sequence of packets in a *.dat
file (file_sink) and then we run the receiver chain using always the
same file as source (file_source).
Repeating several times the
26 matches
Mail list logo
