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

Devin Kelly dwwkelly at gmail.com
Thu Jul 23 17:49:23 EDT 2020


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


More information about the USRP-users mailing list