Just a thought. Could this be the overhead of the new stream tags? Since I didn't see it before.
On Thu, Nov 3, 2011 at 10:23 PM, Tuan (Johnny) Ta <ta.tu...@gmail.com>wrote: > 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
