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

Devin Kelly dwwkelly at gmail.com
Fri Jul 24 10:51:31 EDT 2020


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



On Fri, Jul 24, 2020 at 10:33 AM Marcus D. Leech via USRP-users <
usrp-users at lists.ettus.com> wrote:

> On 07/24/2020 10:28 AM, Devin Kelly via USRP-users wrote:
>
> OK, I'm not sure what SPP is but I'll find it.
>
> I'm also not using GNU Radio if that's what you mean by "radio block XML
> file".
>
> Thanks again,
> Devin
>
> The "spp" parameter is "samples per packet".  It's a stream argument:
>
> https://files.ettus.com/manual/structuhd_1_1stream__args__t.html
>
>
> On Fri, Jul 24, 2020 at 10:19 AM Rob Kossler <rkossler at nd.edu> wrote:
>
>> spp can be changed in the radio block xml file
>>
>> On Thu, Jul 23, 2020 at 9:20 PM Marcus D Leech via USRP-users <
>> usrp-users at lists.ettus.com> wrote:
>>
>>> Try using the Spp parameter in the device ages.
>>>
>>> Sent from my iPhone
>>>
>>> On Jul 23, 2020, at 5:50 PM, Devin Kelly via USRP-users <
>>> usrp-users at lists.ettus.com> wrote:
>>>
>>> 
>>> Hello,
>>>
>>> I'm having an issue where tx_stream->get_max_num_samps() is returning
>>> 364 (for sc16) despite my MTU being set to 9000.
>>>
>>> I modified tx_timed_samples to print out how many samples I can place in
>>> each packet, the number is always 364.
>>>
>>> 364 samples makes sense for an MTU of 1500 bytes, 364 * 2 * 2 = 1456
>>> bytes.  Two bytes per sample, one sample for I and another sample for Q.
>>>
>>> $ ./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: EEPROM Write
>>> Failed!
>>> [WARNING] [GPS] update_cache: Malformed GPSDO string: EEPROM Write
>>> Failed!
>>> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
>>> 0xF1F0D00000000000)
>>> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1313 MB/s)
>>> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1306 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
>>>
>>> Waiting for async burst ACK... success
>>>
>>> Done!
>>>
>>> I've verified that my interface is using a 9000 byte MTU:
>>>
>>> $ ip l show dev p4p2
>>> 4: p4p2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP
>>> mode DEFAULT group default qlen 4000
>>>     link/ether 00:0a:f7:da:6a:e9 brd ff:ff:ff:ff:ff:ff
>>>
>>> And that it actually works:
>>>
>>> $ ping -I p4p2 -c1 -s 8100 192.168.30.2
>>> PING 192.168.30.2 (192.168.30.2) from 192.168.30.1 p4p2: 8100(8128)
>>> bytes of data.
>>> 8108 bytes from 192.168.30.2: icmp_seq=1 ttl=32 time=23.7 ms
>>>
>>> --- 192.168.30.2 ping statistics ---
>>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
>>> rtt min/avg/max/mdev = 23.705/23.705/23.705/0.000 ms
>>>
>>> Note that the "don't fragment" flag is set:
>>>
>>> $ sudo tcpdump -nn -vv -i p4p2 icmp
>>> tcpdump: listening on p4p2, link-type EN10MB (Ethernet), capture size
>>> 262144 bytes
>>> 17:25:12.973794 IP (tos 0x0, ttl 64, id 5942, offset 0, flags [DF],
>>> proto ICMP (1), length 8128)
>>>     192.168.30.1 > 192.168.30.2: ICMP echo request, id 47608, seq 1,
>>> length 8108
>>> 17:25:12.997481 IP (tos 0x0, ttl 32, id 0, offset 0, flags [DF], proto
>>> ICMP (1), length 8128)
>>>     192.168.30.2 > 192.168.30.1: ICMP echo reply, id 47608, seq 1,
>>> length 8108
>>>
>>>
>>> Strangely though using a slightly larger packet (8300 bytes) my USRP
>>> seems to not respond:
>>>
>>> $ ping -I p4p2 -c1 -s 8300 192.168.30.2
>>> PING 192.168.30.2 (192.168.30.2) from 192.168.30.1 p4p2: 8300(8328)
>>> bytes of data.
>>> ^C
>>> --- 192.168.30.2 ping statistics ---
>>> 1 packets transmitted, 0 received, 100% packet loss, time 0ms
>>>
>>> $ sudo tcpdump -nn -vv -i p4p2 icmp
>>> tcpdump: listening on p4p2, link-type EN10MB (Ethernet), capture size
>>> 262144 bytes
>>> 17:23:03.060789 IP (tos 0x0, ttl 64, id 23157, offset 0, flags [DF],
>>> proto ICMP (1), length 8328)
>>>     192.168.30.1 > 192.168.30.2: ICMP echo request, id 47339, seq 1,
>>> length 8308
>>>
>>>
>>> Do I have to do anything besides simply changing my MTU to get the UHD
>>> to take advantage of jumbo frames?
>>>
>>> Thanks for any help,
>>> Devin
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users at lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users at lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>
> _______________________________________________
> USRP-users mailing listUSRP-users at lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> 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/e58cd191/attachment.html>


More information about the USRP-users mailing list