Re: [Discuss-gnuradio] Strange behavior in digital benchmark examples

[Tuan (Johnny) Ta]

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

On Thu, Nov 3, 2011 at 4:54 PM, Josh Blum <address@hidden> wrote:

On 11/03/2011 01:28 PM, Tuan (Johnny) Ta wrote:
> 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 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

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio