Hi ,community @yipingwang @khushbur
I connected the LS1028A to a TSN switch, with the ENETC0 port of the LS1028A configured as a slave clock.
At the application layer, I wrote a program that uses SO_TXTIME to timestamp each transmitted packet, sending one packet every 1 ms.
Using tsntool, I configured the gate control list (GCL) to fully open all gates (i.e., 0xff mode).
However, I observed that some packets have abnormal timestamps. These packets are eventually dropped — although Linux does not report any packet drops, I confirmed the loss through packet capture with Wireshark.
You can see that packet number 1667335 has a hardware timestamp of 1697.332212, which is earlier than both the preceding and following packets.
This is clearly incorrect — the timestamps should be monotonically increasing, as only one packet is sent every millisecond.
Upon further inspection, I found that this packet was never actually transmitted, and was silently dropped.
As long as I don’t enable Qbv, this issue does not occur. Have you observed this phenomenon before? How can it be resolved? Is it a driver issue or a hardware problem?
My kernel version is：
Linux ls1028ardb 6.1.22-rt8 #1 SMP PREEMPT_RT Fri Mar 21 10:37:06 CST 2025 aarch64 GNU/Linux
The fix patch for switch will be merged in Realtime-edge-v3.2, it will be released in early August.
Customer can wait for it.
Thanks
Hi @yipingwang
May I ask if the SWP port might have the same issue? Is there a similar patch available? So far, I have only tested the ENETC port, but I will also need to use the SWP port in the future.
Thank you
Customer can refer to the attached patch, it has been merged in Real-time edge v2.7.
Hi @yipingwang
I'm using ENETC0, and real-time-edge version is v2.6.
which port is customer using? enetc or switch?
which version of real-time edge? I will check the patch for specified version.
I’m currently using the QBV (Time-Aware Shaper) mode on the network interface card. I’ve noticed that the issue only occurs when the device becomes a slave clock during time synchronization.
Here’s the sequence of events:
1. I first start the application to send data — everything works fine at this stage.
2. Then I enable the QBV configuration — still no problem.
3. After that, I start the time synchronization service — still no issue.
4. However, as soon as the time sync process determines that this device is a slave, and it adjusts its local time to align with the master clock, that’s when the problem starts: the send function fails due to a full send buffer.
5. The app returns sendmsg() to 239.255.2.61:17226 failed (Err: Resource temporarily unavailable)
6. Then I reconfigure the qbv, everything works fine.
I want to know if there is an order dependency when acting as a slave clock and working with an application. For example, do I have to wait until time synchronization is completed before enabling QBV? If I enable QBV first and then perform time synchronization, will the clock adjustment process cause QBV to be disabled?
BTW the lsdk version I used is real-time-edge-v2.6
Which version of LSDK is customer using?
How to config GCL entries? you can post the tsntool commands here.
Suggest customer to use tcpdump to capture packets, instead of wireshark.
If enabling Qbv, should ensure the bandwidth/priority of PTP stream, if no bandwidth reserved for PTP,
the frames will sometimes be dropped.