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

Devin Kelly dwwkelly at gmail.com
Fri Jul 24 10:53:46 EDT 2020


For what it's worth I'm on RHEL 7 using this kernel:

Linux <hostname> 3.10.0-1127.13.1.el7.x86_64 #1 SMP Fri Jun 12 14:34:17 EDT
2020 x86_64 x86_64 x86_64 GNU/Linux

Devin

On Fri, Jul 24, 2020 at 10:51 AM Devin Kelly <dwwkelly at gmail.com> 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
>
>
>
> 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/1efd5f62/attachment.html>


More information about the USRP-users mailing list