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

Devin Kelly dwwkelly at gmail.com
Fri Jul 24 10:28:20 EDT 2020


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

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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20200724/fd6c14e6/attachment.html>


More information about the USRP-users mailing list