This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
RTOS/AM4376: PRU-ICSS driver performance
Part Number: AM4376
We expirience rare problems with both PRP mode via PRU-ICSS and PRU_EMAC when PRU stops transferring packets for short period of time. I managed to identify that it caused by PRU by taking PRP statistics. Currently it happens on PRU-ICSS-HSR-PRP-DAN_01.00.03.02 package but I do not hope it is fixed in PRU-ICSS-HSR-PRP-DAN_01.00.04.02, though I will try to migrate my code.
The time is around 32.5ms.
We send packets with constant rate (sampled valued data) and this problem sometimes happens once per 10 seconds, sometimes once per half hour. But the the pause in RX (32.5ms) is more or less constant.
For me it looks like internal watchdog reboot of PRU or kind of DDoS protection, but I'm not sure and have no idea of how to proof that theory.
I'm now trying to migrate to 01.00.04.02 to check if fixed already, but I'd like to hear if it is known issue and if this time means something to TI developers.
In reply to Alexander Aganichev:
Alex, I did miss those patches as you mentioned that you removed most of unnecessary code. Will continue to try to reproduce the issue. Also I have forwarded your responses to those questions from team... Regards, Garrett
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Garrett Ding:
For sampled values we don't use IP, so I removed IP stack initialization.
Here is C# code on top of PCAP which I used for testing. It works on my notebook Win7Pro x64 with Intel card, but caused BSOD on my desktop Win10Pro x64 with Realtek. That seems to be incompatibility with PCAP/Realtek drivers pair, though I'm not sure. The app is looking for interface with address 10.0.1.1 to send packets, you can change it in the code.
The PC app is sending sampled values packets in group of 3 by default, each group of packet is numbered from 0 to 3999 within a roughly second. The small_main.c in the task taskLedBlink2 checks order of received packets and prints received (Curr) and expected (Exp) counter for the packet.
Today I run it in few configurations:
1) PC<-1G->Switch 1G<-100M->IDK, the problem reproduced
2) PC<-100M->Switch 1G<-100M->IDK, the problem not reproduced but the Windows drops frame rate on unknown reason; there also was noted two big gaps in frames but the PRU statistics were clean, so I'm not sure what caused that
3) PC<-1G->Switch 1G<-100M->Switch 100M<-100M->IDK, the problem reproduced
I added printing of interval time in microseconds for which packets not received to small_main.c.
Here it is. I noticed that with increasing number of streams the errors appearance increasing. The RawSocket.exe app took two arguments: first is the repeat timer (250us by default) and the second is number of streams. By calling "RawSocket.exe 250 8" you can simulate 8 SV streams and the problem will appear very quick. If I calcualted correctly it is about 33 Mbit/s load and I may expect random packet drop with 100 Mbit/s interface, but I don't understand why PRU stops receiving for the period of time.
Though with 8 SV streams I don't see direct correlation between the number of streams and "pause time", but for 3 SV the time is always around 33ms and for 4 SV - 75 ms.
I ported this test to idk572x using PDK 1.0.14 and I was able to reproduce same issue.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.