# Questions about benchmark\_tx/benchmark\_rx **URL:** \ **Category:** GNU Radio\ **Created:** [June 1, 2012, 7:02pm UTC](https://www.ruby-forum.com/t/questions-about-benchmark-tx-benchmark-rx/220208 "2012-06-01T19:02:45Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![aris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/258eb7/32.png) [@aris](https://www.ruby-forum.com/u/aris)\ **Post date:** [June 1, 2012, 7:02pm UTC](https://www.ruby-forum.com/t/questions-about-benchmark-tx-benchmark-rx/220208/1 "2012-06-01T19:02:45Z")
I used the benchmark\_tx and benchmark\_rx to transmit data and I have some questions: 1. I set the frequency of both benchmark\_tx and benchmark\_rx to 300M, the transmission succeed; but it failed when I set the frequency to 2.4G or other frequencies. Why is this? 2. Both the benchmark\_tx and benchmark\_rx gives the warning as I marked red: the actual frequency is not same but the transmission succeed. Why is it? 3. In the receiving end, the pktno is disordered some pktnos are much larger than averages. Why is it? 4. What does the n\_right=0 means? Does it mean the packet is corrupted in the receiving end? _The benchmark\_tx messages as following:_ belltestbed@belltestbed-OptiPlex-790 :~/Desktop/gnuradio/gr-digital/les/narrowband$ ./benchmark\_tx.py -f 300M –from-file=pic.jpg linux; GNU C++ version 4.6.3; Boost\_104601; UHD\_003.004.002-128-g12f7a5c9 > > > gr\_fir\_ccf: using SSE > > > – Opening a USRP2/N-Series device… > > > – Current recv frame size: 1472 bytes > > > – Current send frame size: 1472 bytes UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 50000000 bytes. Actual sock buff size: 1000000 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem\_max=50000000 UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 50000000 bytes. Actual sock buff size: 1000000 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem\_max=50000000 UHD Warning: The send buffer could not be resized sufficiently. Target sock buff size: 1048576 bytes. Actual sock buff size: 1000000 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.wmem\_max=1048576 UHD Warning: Unable to set the thread priority. Performance may be negatively affected. Please see the general application notes in the manual for instructions. EnvironmentError: OSError: error in pthread\_setschedparam No gain specified. Setting gain to 17.500000 (from [0.000000, 35.000000]) UHD Warning: The hardware does not support the requested TX frequency: Target frequency: 300.000000 MHz Actual frequency: 4500.000000 MHz UHD Warning: The hardware does not support the requested TX sample rate: Target sample rate: 0.050000 MSps Actual sample rate: 0.195312 MSps Symbol Rate: 25000.000000 Requested sps: 2.000000 Given sample rate: 195312.500000 Actual sps for rate: 7.812500 Requested sample rate: 50000.000000 Actual sample rate: 195312.500000 Using Volk machine: avx\_32 Warning: failed to enable realtime scheduling … _And the benchmark\_rx messages as follwing:_ bell@bell-HP-Compaq-4000-Pro-SFF-PC :~/Desktop/USRP/gnuradio/gr-digital/examples/narrowband$ ./benchmark\_rx.py -f 300M linux; GNU C++ version 4.6.3; Boost\_104601; UHD\_003.004.001-129-g23344268 > > > gr\_fir\_ccf: using SSE > > > – Opening a USRP2/N-Series device… > > > – Current recv frame size: 1472 bytes > > > – Current send frame size: 1472 bytes UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 50000000 bytes. Actual sock buff size: 1000000 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem\_max=50000000 UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 50000000 bytes. Actual sock buff size: 1000000 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem\_max=50000000 UHD Warning: The send buffer could not be resized sufficiently. Target sock buff size: 1048576 bytes. Actual sock buff size: 1000000 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.wmem\_max=1048576 UHD Warning: Unable to set the thread priority. Performance may be negatively affected. Please see the general application notes in the manual for instructions. EnvironmentError: OSError: error in pthread\_setschedparam No gain specified. Setting gain to 49.500000 (from [0.000000, 99.000000]) UHD Warning: The hardware does not support the requested RX frequency: Target frequency: 300.000000 MHz Actual frequency: 2400.000000 MHz UHD Warning: The hardware does not support the requested RX sample rate: Target sample rate: 0.050000 MSps Actual sample rate: 0.195312 MSps Symbol Rate: 25000.000000 Requested sps: 2.000000 Given sample rate: 195312.500000 Actual sps for rate: 7.812500 Requested sample rate: 50000.000000 Actual sample rate: 195312.500000 Warning: Failed to enable realtime scheduling. Using Volk machine: ssse3\_32 ok = False pktno = 3850 n\_rcvd = 1 n\_right = 0 ok = False pktno = 53042 n\_rcvd = 2 n\_right = 0 ok = False pktno = 61454 n\_rcvd = 3 n\_right = 0 ok = False pktno = 27 n\_rcvd = 4 n\_right = 0 ok = False pktno = 41 n\_rcvd = 5 n\_right = 0 ok = False pktno = 44 n\_rcvd = 6 n\_right = 0 ok = False pktno = 44 n\_rcvd = 7 n\_right = 0 ok = False pktno = 51 n\_rcvd = 8 n\_right = 0 ok = False pktno = 43 n\_rcvd = 9 n\_right = 0 ok = False pktno = 64 n\_rcvd = 10 n\_right = 0 I am using two USRP N210. ---
**Author:** ![Weixian\_Z](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/6de8d8/32.png) [@Weixian\_Z](https://www.ruby-forum.com/u/Weixian_Z)\ **Post date:** [June 1, 2012, 7:24pm UTC](https://www.ruby-forum.com/t/questions-about-benchmark-tx-benchmark-rx/220208/2 "2012-06-01T19:24:22Z")
> UHD Warning: > The hardware does not support the requested TX frequency: > Target frequency: 300.000000 MHz > Actual frequency: 4500.000000 MHz > > UHD Warning: > The hardware does not support the requested TX sample rate: > Target sample rate: 0.050000 MSps > Actual sample rate: 0.195312 MSps 1. Be careful to pick frequencies and sample rates that the hardware is capable of handling. That will help you immensely. Here is a list of freq ranges for each particular daughter-board: [http://files.ettus.com/uhd\_docs/manual/html/dboards.html](http://files.ettus.com/uhd_docs/manual/html/dboards.html) 1. I recommend debugging at a lower level to ensure the fidelity of your setup, like a test tone, and so on. -josh ---
**Author:** ![Weixian\_Z](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/6de8d8/32.png) [@Weixian\_Z](https://www.ruby-forum.com/u/Weixian_Z)\ **Post date:** [June 1, 2012, 9:42pm UTC](https://www.ruby-forum.com/t/questions-about-benchmark-tx-benchmark-rx/220208/3 "2012-06-01T21:42:16Z")
On Fri, Jun 1, 2012 at 1:01 PM, Weixian Z. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > I used the benchmark\_tx and benchmark\_rx to transmit data and I have some > questions: > > 1. I set the frequency of both benchmark\_tx and benchmark\_rx to 300M, the > transmission succeed; but it failed when I set the frequency to 2.4G or > other frequencies. Why is this? What daughter board u are using, maybe your daughter board doesn’t support 2.4GHz, Target frequency: 300.000000 MHz Actual frequency: 4500.000000 MHz means u daughter board runs on 4.5GHz > 1. Both the benchmark\_tx and benchmark\_rx gives the warning as I marked > red: the actual frequency is not same but the transmission succeed. Why is > it? Target frequency: 300.000000 MHz Actual frequency: 4500.000000 MHz means u daughter board runs on 4.5GHz, maybe it doesn’t support 300MHz > 1. In the receiving end, the pktno is disordered some pktnos are much > larger than averages. Why is it? They are disrupted, so maybe some random numbers 1. What does the n\_right=0 means? Does it mean the packet is corrupted in > the receiving end? n\_right means how many packets are correctly received, which means their crc check should be true (ok=True)