Maximum Frame Size = 1472 bytes

69 views
Skip to first unread message

praghur

unread,
Aug 16, 2024, 7:55:05 PM8/16/24
to Powder Users
Hello all.

When I run x310-1, x310-2 and 3 as gNBs, only x310-1's MTU is set to 8000. The other two x310s (x310-2 and x310-3) MTU is set at 1472 bytes. Hence, when I try to run the .yml file for x310-2 and x310-3, I get the error of:

[INFO] [X300] Maximum frame size: 1472 bytes.
[WARNING] [X300] You requested a receive frame size of (8000) but your NIC's max frame size is (1472).Please verify your NIC's MTU setting using 'ip link' or set the recv_frame_size argument appropriately.UHD will use the auto-detected max frame size for this connection.
[WARNING] [X300] You requested a send frame size of (8000) but your NIC's max frame size is (1472).Please verify your NIC's MTU setting using 'ip link' or set the send_frame_size argument appropriately.UHD will use the auto-detected max frame size for this connection.
[WARNING] [X300] For the 192.168.40.2 connection, UHD recommends a send frame size of at least 8000 for best
performance, but your configuration will only allow 1472.This may negatively impact your maximum achievable sample rate.
Check the MTU on the interface and/or the send_frame_size argument.

I saw Dustin's response on the post to change the MTU of the network interface connected to the radio to 9000. When I use the command 'ip a', I do not see interface with IP address 192.168.40.2 since that is the address of UHD Device itself. 

192.168.40.2 does not belong to any of my NICs. I did change the MTU of the interfaces on my end as shown below in any case.

eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
    link/ether e4:43:4b:61:1f:10 brd ff:ff:ff:ff:ff:ff
    altname enp24s0f1
    inet 192.168.40.20/24 brd 192.168.40.255 scope global eno2
       valid_lft forever preferred_lft forever
    inet6 fe80::e643:4bff:fe61:1f10/64 scope link
       valid_lft forever preferred_lft forever

I also tried power cycling x310-2 but it did not help. Is there a way to manually set 192.168.40.2's MTU to 9000? how do I find the name of the interface since 192.168.40.2 does not appear on the list of IPs on my end? Please let me know.

Thanks in advance.


Dustin Maas

unread,
Aug 16, 2024, 8:37:50 PM8/16/24
to 'praghur' via Powder Users

It’s the MTU on the host-side interface that you need to set to 9000, which looks to be correct on the node associated with x310-1 (iface eno2 in this case).

root@ota-x310-1-gnb1:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether e4:43:4b:61:05:ba brd ff:ff:ff:ff:ff:ff
    altname enp24s0f0
    inet 155.98.37.214/22 metric 1024 brd 155.98.39.255 scope global eno1
       valid_lft forever preferred_lft forever
    inet6 fe80::e643:4bff:fe61:5ba/64 scope link
       valid_lft forever preferred_lft forever
3: eno3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether e4:43:4b:61:05:da brd ff:ff:ff:ff:ff:ff
    altname enp1s0f0
4: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
    link/ether e4:43:4b:61:05:bc brd ff:ff:ff:ff:ff:ff
    altname enp24s0f1
    inet 192.168.40.10/24 brd 192.168.40.255 scope global eno2
       valid_lft forever preferred_lft forever
    inet6 fe80::e643:4bff:fe61:5bc/64 scope link
       valid_lft forever preferred_lft forever
5: eno4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether e4:43:4b:61:05:db brd ff:ff:ff:ff:ff:ff
    altname enp1s0f1
6: enp134s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether f8:f2:1e:4d:27:b0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.10/24 brd 192.168.1.255 scope global enp134s0f0
       valid_lft forever preferred_lft forever
    inet6 fe80::faf2:1eff:fe4d:27b0/64 scope link
       valid_lft forever preferred_lft forever
7: enp134s0f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether f8:f2:1e:4d:27:b1 brd ff:ff:ff:ff:ff:ff

I don’t see the warning about MTU in the output of uhd_usrp_probe there. Make sure that the same is true on node associated with x310-2 and you should be fine.

-Dustin

--
You received this message because you are subscribed to the Google Groups "Powder Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to powder-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/powder-users/3819d20c-a924-4e0f-8605-deff72fcc0f7n%40googlegroups.com.

Priya Raghuraman

unread,
Aug 16, 2024, 8:49:57 PM8/16/24
to powder...@googlegroups.com
Hi Dustin.  

Sorry if my description was confusing. I did change the MTU in eno2 of x310-2 and x310-3 to 9000. However, I am still getting the same error of:

[INFO] [X300] Maximum frame size: 1472 bytes.
[WARNING] [X300] You requested a receive frame size of (8000) but your NIC's max frame size is (1472).Please verify your NIC's MTU setting using 'ip link' or set the recv_frame_size argument appropriately.UHD will use the auto-detected max frame size for this connection.
[WARNING] [X300] You requested a send frame size of (8000) but your NIC's max frame size is (1472).Please verify your NIC's MTU setting using 'ip link' or set the send_frame_size argument appropriately.UHD will use the auto-detected max frame size for this connection.
[WARNING] [X300] For the 192.168.40.2 connection, UHD recommends a send frame size of at least 8000 for best
performance, but your configuration will only allow 1472.This may negatively impact your maximum achievable sample rate.
Check the MTU on the interface and/or the send_frame_size argument.

X310-1 works fine. I am facing this issue in x310-2 and 3 only. 


You received this message because you are subscribed to a topic in the Google Groups "Powder Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/powder-users/tM3sljsd5Dg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to powder-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/powder-users/6B5A755C-0CC0-46D1-B407-9EAA93BF410F%40gmail.com.

Dustin Maas

unread,
Aug 16, 2024, 9:02:49 PM8/16/24
to 'Priya Raghuraman' via Powder Users

Ah.. I misread. Let me look again..

Dustin Maas

unread,
Aug 16, 2024, 9:37:58 PM8/16/24
to 'Priya Raghuraman' via Powder Users

Something very strange is going on here. Somehow I think all of your d740s are connected to x310-1. I confirmed this by using uhd_find_devices on each of the nodes:

root@ota-x310-1-gnb1:~# uhd_find_devices
[INFO] [UHD] linux; GNU C++ version 11.4.0; Boost_107400; UHD_4.7.0.0-0ubuntu1~jammy1
--------------------------------------------------
-- UHD Device 0
--------------------------------------------------
Device Address:
    serial: 3176D9A
    addr: 192.168.40.2
    fpga: XG
    name:
    product: X310
    type: x300
root@ota-x310-2-gnb2:/local/repository# uhd_find_devices
[INFO] [UHD] linux; GNU C++ version 11.4.0; Boost_107400; UHD_4.7.0.0-0ubuntu1~jammy1
--------------------------------------------------
-- UHD Device 0
--------------------------------------------------
Device Address:
    serial: 3176D9A
    addr: 192.168.40.2
    fpga: XG
    name:
    product: X310
    type: x300
root@ota-x310-3-gnb3:~# uhd_find_devices
[INFO] [UHD] linux; GNU C++ version 11.4.0; Boost_107400; UHD_4.7.0.0-0ubuntu1~jammy1
--------------------------------------------------
-- UHD Device 0
--------------------------------------------------
Device Address:
    serial: 3176D9A
    addr: 192.168.40.2
    fpga: XG
    name:
    product: X310
    type: x300

Note that serial number is the same across the nodes. I think this would explain the other issue you noticed. I’d go through your profile and look for errors in the networking setup.

I suppose this could be a platform issue, but I kind of doubt it. Maybe other POWDER staff can chime in.

-Dustin

Leigh Stoller

unread,
Aug 16, 2024, 10:05:13 PM8/16/24
to 'Priya Raghuraman' via Powder Users


> On Aug 16, 2024, at 2:37 PM, Dustin Maas <dusti...@gmail.com> wrote:
>
> Note that serial number is the same across the nodes. I think this would explain the other issue you noticed. I’d go through your profile and look for errors in the networking setup.
> I suppose this could be a platform issue, but I kind of doubt it. Maybe other POWDER staff can chime in.

I noticed the routes are odd. Any ideas how the routes got set this way?

root@ota-x310-2-gnb2:~# netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
default control-router. 0.0.0.0 UG 0 0 0 eno1
10.0.0.0 ota-x310-3-gnb3 255.0.0.0 UG 0 0 0 enp134s0f1
10.10.0.0 ota-x310-1-gnb1 255.255.252.0 UG 0 0 0 enp134s0f1
boss.emulab.net control-router. 255.255.255.255 UGH 0 0 0 eno1
155.98.36.0 0.0.0.0 255.255.252.0 U 0 0 0 eno1
control-router. 0.0.0.0 255.255.255.255 UH 0 0 0 eno1
192.168.0.0 ota-x310-3-gnb3 255.255.0.0 UG 0 0 0 enp134s0f1
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 enp134s0f1
192.168.40.0 ota-x310-1-gnb1 255.255.255.240 UG 0 0 0 enp134s0f1
192.168.40.0 0.0.0.0 255.255.255.0 U 0 0 0 eno2

and

root@ota-x310-2-gnb2:~# ip route get 192.168.40.2
192.168.40.2 via 192.168.1.10 dev enp134s0f1 src 192.168.1.11 uid 0


Priya Raghuraman

unread,
Aug 16, 2024, 11:16:42 PM8/16/24
to powder...@googlegroups.com
Huhh. That is indeed weird. I am debugging this issue with a smaller system with only 2 nodes instead of 3 using the experiment link --Powder - Experiment Status (powderwireless.net). I am facing a similar issue with 2 nodes too. 

The topology view looks good to me. I will check in the profile further to see if I am making a mistake somewhere during the setup. 
image.png

Dustin Maas

unread,
Aug 17, 2024, 12:13:45 AM8/17/24
to 'Priya Raghuraman' via Powder Users
Ah.. thanks Leigh.

Priya: are you running an scripts that might be setting the routes this way? or manually setting them this way for some reason?
> --
> You received this message because you are subscribed to the Google Groups "Powder Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to powder-users...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/powder-users/9EA1F1AE-48E1-4466-92C4-721425A3BE3C%40gmail.com.

Priya Raghuraman

unread,
Aug 17, 2024, 12:18:37 AM8/17/24
to powder...@googlegroups.com
I am not manually setting up the routing. I am not aware of any script in my repository that is setting up the route this way. 

You received this message because you are subscribed to a topic in the Google Groups "Powder Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/powder-users/tM3sljsd5Dg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to powder-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/powder-users/9514E786-EC74-4D24-8F97-24117A478F39%40gmail.com.

Dustin Maas

unread,
Aug 17, 2024, 12:56:42 AM8/17/24
to 'Priya Raghuraman' via Powder Users

Hmm. The MTUs were not correctly set in this new experiment. I set them appropriately and it is working as expected.

I have a hunch about what is happening in the other version of the profile as well. Do me a favor and change your profile to set all sdr ifaces on the nodes to 192.168.40.1. Looks like you changed those for some reason, but I don’t think that is necessary.

-Dustin

Reply all
Reply to author
Forward
0 new messages