# Overflows in benchmark\_rx.py **URL:** \ **Category:** GNU Radio\ **Created:** [February 16, 2013, 3:47am UTC](https://www.ruby-forum.com/t/overflows-in-benchmark-rx-py/226631 "2013-02-16T03:47:13Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Manu\_T\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea5d25/32.png) [@Manu\_T\_S](https://www.ruby-forum.com/u/Manu_T_S)\ **Post date:** [February 16, 2013, 3:47am UTC](https://www.ruby-forum.com/t/overflows-in-benchmark-rx-py/226631/1 "2013-02-16T03:47:13Z")
Hi, I was running the benchmark scripts with the following set of parametrs -f 915M -r 5000000 -m psk -8 with 30 dB gain set on both Tx and Rx. I was getting cluttered overflows and packet received during that time are in error… Like I’m receiving about a 1000 packet without error and then then system runs into overflow and about then quite a large number of packets are received in error. Output is posted Demodulator: bits per symbol: 3 RRC roll-off factor: 0.35 FLL bandwidth: 6.28e-02 Timing bandwidth: 6.28e-02 Phase bandwidth: 6.28e-02 – Opening a USRP2/N-Series device… – Current recv frame size: 1472 bytes – Current send frame size: 1472 bytes UHD Receiver: UHD Args: Freq: 915MHz Gain: 30.000000 dB Sample Rate: 3.33333Msps Antenna: None Spec: None Demodulator: bits per symbol: 3 RRC roll-off factor: 0.35 FLL bandwidth: 6.28e-02 Timing bandwidth: 6.28e-02 Phase bandwidth: 6.28e-02 Receive Path: modulation: psk\_demod bitrate: 5Mb/s samples/symbol: 2.0000 Differential: True Using Volk machine: avx\_64\_mmx ok = True pktno = 1 n\_rcvd = 1 n\_right = 1 ok = True pktno = 2 n\_rcvd = 2 n\_right = 2 ok = True pktno = 3 n\_rcvd = 3 n\_right = 3 . . . ok = True pktno = 2953 n\_rcvd = 2953 n\_right = 2953 ok = True pktno = 2954 n\_rcvd = 2954 n\_right = 2954 ok = True pktno = 2955 n\_rcvd = 2955 n\_right = 2955 ok = True pktno = 2956 n\_rcvd = 2956 n\_right = 2956 ok = False pktno = 2957 n\_rcvd = 2957 n\_right = 2956 ok = False pktno = 2959 n\_rcvd = 2958 n\_right = 2956 ok = False pktno = 2961 n\_rcvd = 2959 n\_right = 2956 ok = False pktno = 2963 n\_rcvd = 2960 n\_right = 2956 ok = False pktno = 2965 n\_rcvd = 2961 n\_right = 2956 ok = False pktno = 2967 n\_rcvd = 2962 n\_right = 2956 . . . ok = False pktno = 3838 n\_rcvd = 3369 n\_right = 2956 ok = False pktno = 3841 n\_rcvd = 3370 n\_right = 2956 ok = False pktno = 3843 n\_rcvd = 3371 n\_right = 2956 ok = True pktno = 3845 n\_rcvd = 3372 n\_right = 2957 ok = True pktno = 3846 n\_rcvd = 3373 n\_right = 2958 ok = True pktno = 3847 n\_rcvd = 3374 n\_right = 2959 ok = True pktno = 3848 n\_rcvd = 3375 n\_right = 2960 . . . Any idea how to avoid these overflows??? ---
**Author:** ![Manu\_T\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea5d25/32.png) [@Manu\_T\_S](https://www.ruby-forum.com/u/Manu_T_S)\ **Post date:** [February 17, 2013, 6:08pm UTC](https://www.ruby-forum.com/t/overflows-in-benchmark-rx-py/226631/2 "2013-02-17T18:08:02Z")
Hi Tom, Thanks for the reply… I teed the output at the Rx to a file. It showed O’s on my screen, but the file had no O’s. I came to know from a friend of mine that the O’s may be going into the stderr and the file had only stdout output. But the errors you see there were actually preceded by O’s. I will run them again after making the changes you suggested. Thank you ---
**Author:** ![Manu\_T\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea5d25/32.png) [@Manu\_T\_S](https://www.ruby-forum.com/u/Manu_T_S)\ **Post date:** [February 17, 2013, 4:29pm UTC](https://www.ruby-forum.com/t/overflows-in-benchmark-rx-py/226631/3 "2013-02-17T16:29:51Z")
On Fri, Feb 15, 2013 at 9:46 PM, Manu T S [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > ## – Current send frame size: 1472 bytes bits per symbol: 3 Using Volk machine: avx\_64\_mmx ok = False pktno = 2957 n\_rcvd = 2957 n\_right = 2956 ok = False pktno = 3843 n\_rcvd = 3371 n\_right = 2956 > > Manu T S This is usually a problem due to the receiver not being able to keep up with the flow of samples from the UHD device. Try running at a lower bitrate. If you’re seeing overflows temporarily and then things are correcting themselves, it looks like you might be right on the edge of your system’s capabilities. In this case, it’s like some other process/task is taking some time away from your app, causing it to slow down just enough to cause problems, but then things look like they come back. You could also try to run with realtime privileges enabled to make sure your process gets priority. On the other hand, the output you show here doesn’t have any overflow indication. Are you sure that this is what’s happening? You’re running at 915 MHz, the center of the 900 MHz ISM band (depending on where you are). It’s likely to have other signals in it. Maybe this is just a case of interference? Tom