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 <j...@joshknows.com> 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 > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
