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

Marcus D. Leech patchvonbraun at gmail.com
Fri Jul 24 10:32:28 EDT 2020


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 
> <mailto: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 <mailto: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
>>         <mailto: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 <http://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 <http://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 <http://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 <http://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 <mailto: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 <mailto: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

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


More information about the USRP-users mailing list