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