discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] make test failure at qa_constellation_receiver


From: Alick Zhao
Subject: Re: [Discuss-gnuradio] make test failure at qa_constellation_receiver
Date: Sun, 15 Apr 2012 00:39:19 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On Sat, 14 Apr 2012 13:40:35 +0200, Martin Braun wrote:
> On Sat, Apr 14, 2012 at 05:20:13PM +0800, Alick Zhao wrote:
>> Yes the bug still occurs.
>>
>> I just wrote a simple script to ran the test for 50 times on T60 with
>> Ubuntu, GNU Radio 3.5.3 equipped, before and after FREQUENCY_OFFSET set
>> to 0. All failed the test. (n_pass is 0/50 in both sets) Every test's
>> output is almost identical in each set except particular test time
>> length. The ones before FREQUENCY_OFFSET change is basically the same as
>> test.t60.log already attached. One of the ones with FREQUENCY_OFFSET set
>> to 0 is attached below. I guess the almost same contents of output is
>> due to fixed random seed.
>>
>> I also ran the script on a Dell desktop with Fedora, and the result is
>> 50/50 pass the test. Then I notice one line in the qa python file says
>> that seed 1234 fails. However, 50/50 are OK with seed 1234 on the Dell
>> desktop.
> 
> So,
> 
> I tried this on a native 32-Bit Ubuntu 11.10, and it fails (tells me
> it's using "Volk machine: sse3_32".
> 
> I also noticed the line that says seed=1234 fails. Also, the seed is set
> multiple times in the script. If this is the source of the bug or not,
> it should be fixed, because the seed is reset somewhere in the guts of
> the test. I'll post a patch on patch-gnuradio--this eliminates the
> problem on my machine, for some reason. If it does the same for you,
> this might actually be the solution.
> 
> MB
> 
> 

I applied the patch and tested it. No failure, yeah!

However, with my debugging line, I can see this:

[...]
constellation: <constellation psk (m=32)>  differential: True  correct:
0.942307692308
constellation: <constellation psk (m=64)>  differential: True  correct:
0.772435897436
constellation: <constellation psk (m=2)>  differential: True  correct: 1.0
[...]

So why 0.77XXX on the second line does not cause the assert to fail?

alick



reply via email to

[Prev in Thread] Current Thread [Next in Thread]