Re: [Discuss-gnuradio] benchmark_* not working correctly

[Dev Ramudit]

I've been looking into this problem further. I apologize in advance for 
the long post. To make things easier, I'll represent the three computers 
I'm using as follows:

32deb - 32bit Debian desktop
32red - 32bit Fedora laptop
64red - 64bit Fedora desktop

benchmark_loopback.py:
---------------------
Does not appear to work properly on either 32deb or 32red. When I set 
the internal noise channel on in the script, I get random results as 
follows. Judging from the correctly running script on the 64 bit system, 
this detection happens every 15-20 "real" packets:


ok = False  pktno = 8355  n_rcvd =    1  n_right =    0
ok = False  pktno =   19  n_rcvd =    2  n_right =    0
ok = False  pktno =   46  n_rcvd =    3  n_right =    0
ok = False  pktno =   33  n_rcvd =    4  n_right =    0
ok = False  pktno =  196  n_rcvd =    5  n_right =    0
... etc.

with different values on each run. When I take the noise channel off 
(channelon = False), I get the following results on 32deb (the time 
between every packet detection is much longer, about 10-20 times as long 
with high variability):


ok = False  pktno =   32  n_rcvd =    1  n_right =    0
ok = False  pktno =    1  n_rcvd =    2  n_right =    0
ok = False  pktno = 32997  n_rcvd =    3  n_right =    0
ok = False  pktno =  142  n_rcvd =    4  n_right =    0
ok = False  pktno =  109  n_rcvd =    5  n_right =    0
... etc.

Running the above repeatedly gives the same pktno and timing every run. 
The same behavior happens on 32red, but the pktnos and timings are 
different. I've tried running the CPU at close to 100% utilization on 
both 32deb and 32red to see if there is some kind of over/underflow 
occurring, but it didn't change the above results.

64red runs correctly, giving the following output:

ok =  True  pktno =    0  n_rcvd =    1  n_right =    1
ok =  True  pktno =    1  n_rcvd =    2  n_right =    2
ok =  True  pktno =    2  n_rcvd =    3  n_right =    3
ok =  True  pktno =    3  n_rcvd =    4  n_right =    4
ok =  True  pktno =    4  n_rcvd =    5  n_right =    5
ok =  True  pktno =    5  n_rcvd =    6  n_right =    6
... etc.


benchmark_rx.py and benchmark_tx.py:
-----------------------------------
I've tried running benchmark_rx and tx with the following 
configurations, in both directions:

32deb <-> 32red
32deb <-> 64red
32red <-> 64red
64red USRP 0 <-> 64red USRP 1

using:
./benchmark_tx.py -T A -f 2.4G
./benchmark_rx.py -R A -f 2.4G

In _no_ case was the receiver able to demod any packets at all. In every 
run I tested usrp_fft.py to verify that a signal was coming through on 
the correct frequency. I exchanged the USRP from 32red to run on 64red, 
but that didn't help either.

I created a file sink after the amp block in benchmark_tx on each 
computer and tested the beginning of each file against the others. It 
seems like the benchmark_tx script is sending the same data to the USRP 
in every case, which means the problem is in the RX side(?)

./benchmark_ofdm.py
-------------------
Works correctly on every computer, showing:


ok: True         pktno: 0        n_rcvd: 1       n_right: 1
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000


ok: True         pktno: 1        n_rcvd: 2       n_right: 2
0101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101
etc...

./benchmark_ofdm_rx.py and ./benchmark_ofdm_tx.py:
-------------------------------------------------
Same configurations as above were tried. In every case except "64red 
USRP 0 <-> 64red USRP 1", nothing was demoded at all. With the 64red 
transmitting to two connected USRPS with:

./benchmark_ofdm_rx.py -U 1 -R A -f 2.4G
./benchmark_ofdm_tx.py -U 0 -T A -f 2.4G

(added -U to the options to select USRP) I get:

ok: False        pktno: 84       n_rcvd: 1       n_right: 0
ok: False        pktno: 85       n_rcvd: 2       n_right: 0
ok: False        pktno: 86       n_rcvd: 3       n_right: 0
ok: False        pktno: 87       n_rcvd: 4       n_right: 0
ok: False        pktno: 88       n_rcvd: 5       n_right: 0

The detection is strangely sporadic, with long series of packets not 
being demoded, followed by 3-4 second bursts of demods.

--------------
Lastly, running the Packet mod/demod example in GRC in the latest 
version works correctly on every system. It displays the sine wave 
correctly, and changes it appropriately with parameter modification.

Any suggestions on how to proceed?

Thanks,
Dev