Strange behavior in digital benchmark examples

GNU Radio
1

Hello all,

I just came across a strange behavior in the digital benchmark examples
that I haven’t seen before. The transmitter wouldn’t stop itself after
it
finishes sending the requested data size (specified by -M argument).
Keyboard interrupt (ctrl+C) has no effect. I had to stop it with ctrl+Z
and
kill the job after.

This behavior starts when bitrate exceeds 1M.

If I ran benchmark_rx2.py then a short period after receiving all
packets
(~30 sec), the receiver would continuously spill out “O” (overrun). This
didn’t happen if I ran benchmark_rx.py. (I ran the corresponding tx
code.)

I’m not sure what could be causing it. I was able to run digital
benchmark
code on my older machine at 1.5Mbps prior to UHD (I used Ethernet
driver)
so I’m sure CPU speed isn’t a problem.

To make it work with UHD driver, I made some changes to the
usrp_options.py
and generic_usrp.py.

I’m quite puzzled right now. I’d appreciate any insights!

Thank you,
Johnny

2

On 11/03/2011 01:28 PM, Tuan (Johnny) Ta wrote:

If I ran benchmark_rx2.py then a short period after receiving all packets
(~30 sec), the receiver would continuously spill out “O” (overrun). This
didn’t happen if I ran benchmark_rx.py. (I ran the corresponding tx code.)

I’m not sure what could be causing it. I was able to run digital benchmark
code on my older machine at 1.5Mbps prior to UHD (I used Ethernet driver)
so I’m sure CPU speed isn’t a problem.

To make it work with UHD driver, I made some changes to the usrp_options.py
and generic_usrp.py.

I believe that tom ported all of the gnuradio “classic” example
applications in 3.5 release. You may want to try those examples, because
I know that he has tested them recently.

I hope that helps,
-Josh

3

Just a thought. Could this be the overhead of the new stream tags? Since
I
didn’t see it before.

4

On 11/03/2011 08:52 PM, Tuan (Johnny) Ta wrote:

Just a thought. Could this be the overhead of the new stream tags? Since I
didn’t see it before.

The tags overhead should be next to nothing. The source block only
produces a tag once on init, and after overflows. The overflows that you
see tell me that the receiver chain is not pulling data out fast enough.
however…

So I was doing a little experiment with the mod/demod blocks and packet
framer/deframer. No USRPs, just a loopback. Somehow, about 2000 packets
(not samples) were getting delayed in the pipeline. Removing the
mod/demod block and replacing it with a packed to unpacked fixed the
delay. So somehow within either mod/demod or both, a crap-ton of samples
were getting buffered.

So something is wrong, not saying that it describes your issue, but it
might. Here is a screen shot of my flow graph:
http://i.imgur.com/ZQtEE.png

-Josh

5

Josh,

I’ve upgraded to 3.5rc0. The same thing happened. I got some more
details:

When I ran benchmark_tx on 1 machine, at low bitrate (0.1Mbps or 0.2MSps

I’m using bpsk) the CPU utilization is roughly 9%.
But the receiver, running benchmark_rx showed 110% CPU utilization.

If I up the bitrate to 1Mbps,
the transmitter showed 90% CPU utilization so it scaled linearly.
the receiver starts out showing 110% CPU utilization, so I guess it
processed noise also, which makes sense because there’s no
carrier-sense.
It did nothing for a while (~30 sec), then started showing correct
receptions. Until a point, it started to show overrun. Here’s part of
the
output on the receiver:

ok = True pktno = 859 n_rcvd = 859 n_right = 859
ok = True pktno = 860 n_rcvd = 860 n_right = 860
ok = True pktno = 861 n_rcvd = 861 n_right = 861
ok = True pktno = 862 n_rcvd = 862 n_right = 862
ok = True pktno = 863 n_rcvd = 863 n_right = 863
ok = True pktno = 864 n_rcvd = 864 n_right = 864
ok = True pktno = 865 n_rcvd = 865 n_right = 865
ok = True pktno = 866 n_rcvd = 866 n_right = 866
ok = True pktno = 867 n_rcvd = 867 n_right = 867
Ook = True pktno = 868 n_rcvd = 868 n_right = 868
OOOok = False pktno = 869 n_rcvd = 869 n_right = 868
OOOOOOOok = False pktno = 879 n_rcvd = 870 n_right = 868
OOOOOOOOOok = False pktno = 902 n_rcvd = 871 n_right = 868
OOOOOOOok = False pktno = 914 n_rcvd = 872 n_right = 868
OOOOOOOOok = False pktno = 929 n_rcvd = 873 n_right = 868
OOOOOOOOOOOok = False pktno = 950 n_rcvd = 874 n_right = 868
OOOOOOOOOOOOOOOok = False pktno = 970 n_rcvd = 875 n_right = 868
OOOOOOOOOOOOOOOOOOOOOOOOOOok = False pktno = 983 n_rcvd = 876
n_right
= 868
OOOOOOOok = False pktno = 987 n_rcvd = 877 n_right = 868
OOOOOOok = False pktno = 990 n_rcvd = 878 n_right = 868
OOOOOOok = False pktno = 993 n_rcvd = 879 n_right = 868
OOOOOOok = False pktno = 996 n_rcvd = 880 n_right = 868

Another thing is when I started the transmitter first, then the receiver
started to show received samples right away. If I started the receiver
first, then it had the 30 sec delay mentioned above.

Before I used to run these code on the old gnuradio version (3.2.2) and
Ethernet driver and didn’t have this problem. Could this be related to
the
new implementation of gnuradio and/or the UHD driver? Or is there any
other
possible explanation?

Thank you,
Johnny

6

I am not seeing the same buffering issues with GMSK. I’ am guessing that
the recent work on gr-digital may have accidentally messed up our d*psk
blocks. Maybe massive filter coefficients are being calculated?

When Tom gets back I think he can offer some insight.

Can you try/compare the GMSK mod/demod blocks instead?

-Josh

7

I think the problematic block might be the FLL used in the PSK
demodulator. I haven’t looked into the issue very deeply, but I have
confirmed that given the same input parameters, the FLL from 3.4.2 works
fine, while the 3.5.0 version causes a lot of overruns.

Jordan

8

On 11/04/2011 01:55 PM, Jordan O. wrote:

I think the problematic block might be the FLL used in the PSK
demodulator. I haven’t looked into the issue very deeply, but I have
confirmed that given the same input parameters, the FLL from 3.4.2
works fine, while the 3.5.0 version causes a lot of overruns.

Thanks, I confirmed that the fll band edge filter is the culprit. The
following diff (removing the bandedge) makes may loopback example far
more responsive:

diff --git a/gr-digital/python/generic_mod_demod.py
b/gr-digital/python/generic_mod_demod.py
index ae876e1…cf2d684 100644
— a/gr-digital/python/generic_mod_demod.py
+++ b/gr-digital/python/generic_mod_demod.py
@@ -303,7 +303,7 @@ class generic_demod(gr.hier_block2):
self._setup_logging()

     # Connect and Initialize base class

  •    blocks = [self, self.agc, self.freq_recov,

  •    blocks = [self, self.agc,
             self.time_recov, self.receiver]
   if differential:
       blocks.append(self.diffdec)

-Josh

9

On 11/04/2011 01:55 PM, Jordan O. wrote:

I think the problematic block might be the FLL used in the PSK
demodulator. I haven’t looked into the issue very deeply, but I have
confirmed that given the same input parameters, the FLL from 3.4.2
works fine, while the 3.5.0 version causes a lot of overruns.

Made an issue and narrowed it down a bit:
http://gnuradio.org/redmine/issues/463

-Josh