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

Devin Kelly dwwkelly at gmail.com
Fri Jul 24 13:04:09 EDT 2020


Well the documentation says RX stream only but it turned out to work for TX
streams too... so the documentation writer should be embarrassed!

In my first message I verified that the HW actually sends 8100 byte packets
using ping, that is unless tcpdump is lying to me or re-constructing IP
packets in a way that's transparent to me.

It seems that there's a frame size that's hard coded in x300_eth_mgr.cpp
and that's what was causing me trouble.  I got get_max_num_samps up to 1996
and so far that's helped the actual application I'm writing substantially.

Devin

On Fri, Jul 24, 2020 at 12:57 PM Marcus D. Leech via USRP-users <
usrp-users at lists.ettus.com> wrote:

> 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.
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20200724/ddac694c/attachment.html>


More information about the USRP-users mailing list