No TOTAL_TX on benetel 550 with srsRAN gNB #677
-
|
Hey all, https://docs.srsran.com/projects/project/en/latest/tutorials/source/oranRU/source/rus/r550.html Thus far we have gottent the benetel to connect to the gNB via DPDK, but we have yet to see any TX packets in the KPIs. When we run the kpi.sh script on the RU we see that all RX packets are recieved on time, but the TX_TOTAL remains 0. We have been thinking the issue has to do with misconfigured eaxc uplink ports, but nothing we have tried is working. Below I have included all of the relevant config files we are using, as well as some additional logs from the benetel. Any help would be appreciated. |
Beta Was this translation helpful? Give feedback.
Replies: 10 comments 4 replies
-
Beta Was this translation helpful? Give feedback.
-
|
Likely a VLAN and/or MAC address mismatch or misconfiguration. Please check the DU MAC address registers in the RU. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, that's a good suggestion, I also have the VLAN ports and MAC address configure on the RU to point to the ethernet nic of the DU: Can you give me any further insight into how I may be misconfiguring these. Any help is greatly appreciated. |
Beta Was this translation helpful? Give feedback.
-
|
Don't use VLAN ID 1 because it's often used as the Port VLAN by default and is thus untagged. But the RU and DU required CU plane to be tagged. |
Beta Was this translation helpful? Give feedback.
-
|
Ah, and also update the FW of the RU to 1.0.4 if you've not done so already. |
Beta Was this translation helpful? Give feedback.
-
|
We changed the VLAN port but it didn't seem to have much effect. We have a connection between the RU and the DU/CU, but the connection has significant delay with RX packets, and still has no TX packets. We are not sure what in our configuration is causing the delay, we have tried changing the VLAN tags MAC addresses and eAxC configurations multiple times. Is there anything in the following logs that you think could be the culprit, as far as having no TX packets: Our gnb log gives the following output: oru_vlan_mac_info on the RU gives the following output: Here are screenshots of how we configured the Falcon switch
Beyond this if there is any information that would be helpful please let me know For reference we are using the firmware you suggested version 1.0.4 Anything helps, we are really stuck on this. |
Beta Was this translation helpful? Give feedback.
-
|
Well, yes, your timing is completely off. Check PTP stats on RU and DU and then tune timing parameters if needed. |
Beta Was this translation helpful? Give feedback.
-
|
What do the trace of the ptp4l and phc2sys look like? I would also add the VLAN "3" into each of the "Allowed VLANs". You only have 1, 2, & 1588. Also I noticed in your gnb config you have the DU mac address as 90:e3:ba:00:12:32 but your recent RU config is 90:e3:ba:00:12:33. Which is it? |
Beta Was this translation helpful? Give feedback.
-
|
Yes of course, Here is the phc2sys logs: Hope this helps |
Beta Was this translation helpful? Give feedback.
-
|
Additionally, we reconfigured the switch to allow traffic on port 3, sorry for the confusion |
Beta Was this translation helpful? Give feedback.
-
|
This: shows that the I assume you are sending timing through a different port as the DPDK? Do you have the timing port set to DHCP? Does the Falcon GUI show that the timing port is active (Green) under Monitor > Ports > State? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks that helped a lot. We have reconfigured ptp and it is now working
properly. This made the rx packets come on time using kpo.sh on the ru. But
the issue is that we still have no TX packets. Any insight on this?
пт, 21 июн. 2024 г., 3:28 PM ffxxcad ***@***.***>:
… This:
ptp4l[3890.130]: port 1 (enp1s0f0): assuming the grand master role
shows that the enp1s0f0 port does not detect or recognize a Grandmaster
Clock. For reference, this is the output you should see:
ptp4l[21142.237]: selected /dev/ptp2 as PTP clock
ptp4l[21142.256]: port 1 (enp81s0f1): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[21142.256]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[21142.257]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[21142.323]: port 1 (enp81s0f1): new foreign master 000580.fffe.0858e2-15
ptp4l[21142.588]: selected best master clock 000580.fffe.0858e2
ptp4l[21142.588]: port 1 (enp81s0f1): LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[21143.163]: port 1 (enp81s0f1): minimum delay request interval 2^-4
ptp4l[21143.481]: port 1 (enp81s0f1): UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[21144.245]: rms 559625 max 1119270 freq -1907 +/- 72 delay 118 +/- 1
ptp4l[21145.370]: rms 3 max 5 freq -1879 +/- 4 delay 120 +/- 1
ptp4l[21146.489]: rms 2 max 4 freq -1879 +/- 3 delay 120 +/- 0
ptp4l[21147.623]: rms 6 max 10 freq -1867 +/- 8 delay 120 +/- 1
ptp4l[21148.737]: rms 4 max 9 freq -1864 +/- 5 delay 118 +/- 0
ptp4l[21149.867]: rms 5 max 7 freq -1878 +/- 3 delay 121 +/- 1
ptp4l[21151.000]: rms 4 max 7 freq -1883 +/- 3 delay 119 +/- 1
ptp4l[21152.126]: rms 3 max 6 freq -1876 +/- 5 delay 120 +/- 1
ptp4l[21153.251]: rms 3 max 5 freq -1881 +/- 5 delay 119 +/- 0
ptp4l[21154.370]: rms 2 max 4 freq -1876 +/- 3 delay 119 +/- 1
ptp4l[21155.489]: rms 2 max 5 freq -1877 +/- 4 delay 120 +/- 0
ptp4l[21156.623]: rms 3 max 5 freq -1883 +/- 3 delay 120 +/- 0
ptp4l[21157.737]: rms 3 max 4 freq -1888 +/- 2 delay 121 +/- 0
ptp4l[21158.875]: rms 4 max 8 freq -1894 +/- 4 delay 120 +/- 1
ptp4l[21159.991]: rms 4 max 6 freq -1884 +/- 4 delay 120 +/- 1
I assume you are sending timing through a different port as the DPDK? Do
you have the timing port set to DHCP? Did you make the Falcon configuration
changes I mentioned above? Does that Falcon GUI show that the timing port
is active (Green) under Monitor > Ports > State?
—
Reply to this email directly, view it on GitHub
<#677 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQMIE362HGJV3C43GO3GN4LZISEFRAVCNFSM6AAAAABJO23WY2VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TQNBTGU2TK>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Are you running the RU in test mode? i.e. Or are you trying to connect a UE? You will only see TX packets when a UE is connected or when test mode is employed. |
Beta Was this translation helpful? Give feedback.
-
|
I see, thanks for the info. I will post how I changed the ptp config since
the one provided in the documentation did not seem correct.
пт, 21 июн. 2024 г., 5:48 PM ffxxcad ***@***.***>:
… Are you running the RU in test mode?
i.e. sudo ./apps/gnb/gnb -c ../configs/config_file.yml test_mode test_ue
--rnti 0x1 --ri 4
Or are you trying to connect a UE? You will only see TX packets when a UE
is connected or when test mode is employed.
—
Reply to this email directly, view it on GitHub
<#677 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQMIE364CR2IZ4GSMKBLVRDZISUS3AVCNFSM6AAAAABJO23WY2VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TQNBUGI3DI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
This:
ptp4l[3890.130]: port 1 (enp1s0f0): assuming the grand master roleshows that the
enp1s0f0port does not detect or recognize a Grandmaster Clock. For reference, this is the output you should see: