[USRP-users] tx_stream->get_max_num_samps() too low

Marcus D. Leech patchvonbraun at gmail.com
Fri Jul 24 12:56:22 EDT 2020


On 07/24/2020 10:51 AM, Devin Kelly via USRP-users wrote:
> I'm confused.  The documentation says SPP applies for receiving, I'm 
> transmitting.
>
> spp: (samples per packet) controls the size of RX packets. When not 
> specified, the packets are always maximum frame size. Users should 
> specify this option to request smaller than default packets, probably 
> with the intention of reducing packet latency.
>
> I also set my tx streamer to this:
>
>     // create a transmit streamer
>     uhd::stream_args_t stream_args("fc32", wire); // complex floats
>     stream_args.args["spp"] = "2000";   // Also tried 200 and 365 here
>     uhd::tx_streamer::sptr tx_stream = usrp->get_tx_stream(stream_args);
>
> Without any luck.  I also tried setting SPP to 200 and that worked, 
> tx_stream->get_max_num_samps() returned 200.  Even setting SPP to 365 
> I still got 364.
>
> $ ./examples/tx_timed_samples --args="name=node4" --nsamps 100000 
> --rate 10e6
>
> Creating the usrp device with: name=node4...
> [INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-39); 
> Boost_106900; UHD_3.15.0.heads-v3.15.0.0-0-gaea0e2de
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Maximum frame size: 8000 bytes.
> [INFO] [X300] Radio 1x clock: 200 MHz
> [INFO] [GPS] Found an internal GPSDO: LC_XO, Firmware Rev 0.929b
> [WARNING] [GPS] update_cache: Malformed GPSDO string: 
> EEPN,07116.0483,W,0.0,0.0,240720,,*28
> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 
> 0xF1F0D00000000000)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1291 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1311 MB/s)
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000000001)
> [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD100000000001)
> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000)
> [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0000000000000)
> [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000000)
> [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0000000000000)
> Using Device: Single USRP:
>   Device: X-Series Device
>   Mboard 0: X310
>   RX Channel: 0
>     RX DSP: 0
>     RX Dboard: A
>     RX Subdev: UBX RX
>   RX Channel: 1
>     RX DSP: 0
>     RX Dboard: B
>     RX Subdev: UBX RX
>   TX Channel: 0
>     TX DSP: 0
>     TX Dboard: A
>     TX Subdev: UBX TX
>   TX Channel: 1
>     TX DSP: 0
>     TX Dboard: B
>     TX Subdev: UBX TX
>
> Setting TX Rate: 10.000000 Msps...
> Actual TX Rate: 10.000000 Msps...
>
> Setting device timestamp to 0...
> tx_stream->get_max_num_samps() = 364
> ...
>
> Devin
>
>
Well, I'm embarrassed :)

Yeah, looks like SPP is for RX streams.

Here's something to try.  Try setting your MTU to a let's say, 3000 
bytes, and see if that changes the behavior?  What about 4000? And so on.

There ARE NIC chips out there where the driver is happy to accept a 
large MTU request, but the hardware doesn't actually honor it.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20200724/f57b06c5/attachment.html>


More information about the USRP-users mailing list