[C6657]UDP packet loss of NDK in helloworld examples

Dear Sung-IL,
How many packets were lost and how many packets were received ?
All the UDP packets ?

They have modified the example code ??

Can you please provide the CCS log ?

Thanks Titusrathinaraj Stalin,

Yes. All the UDP packets. When they sent 2000 packets, they got 1966~1980 packets and 20~34 packets were lost.

They have not modified example code, and they got similar results even when they tested with pre-built file( 

\\mcsdk_2_01_02_06\examples\ndk\helloWorld\evmc6657l\Debug\helloworld_evmc6657l.out )

I attached their CCS log in below.

Thanks and Best Regards,

SI.

Hi Titusrathinaraj Stalin,

Have you check this?
Have you seen same result in your test?

I think this issue was caused by task priority issues., and are you agree on this?

Thanks and Best Regards,
SI.

S.I.

I don't know if what I saw here is your reported issue:

1) I loaded the pre-build \ti\mcsdk_2_01_02_06\examples\ndk\helloWorld\evmc6657l\Debug\helloworld_evmc6657l.out into C6657 DSP core 0.

2) Run and I got an IP address through DHCP

3) Then I ping this address from my PC, the PC and C6657EVM are connected to a GbE switch, then to the corporate network. The PING is ICMP packets at every 1 second. I don't know what kinds of UDP traffic the customer is generating towards 6657.

4) I observed two failures: first is about Rx 1990 packets, the 6657 is not responding to Ping. The second failure happens quicker when Rx about 180 packets.

Regards, Eric

I tested the same on C6678 EVM with ping 3600 packets (1 hour), I didn't see any issue. I want to check with you if the ICMP ping failure on C6657 is the real issue on customer side. Or, they need to clarify how they tested and how do they find UDP packet loss.
Regards, Eric

Hi Eric,

My customer did not use GbE switch and make EVM be connected directly to PC without GbE switch. They sent 83bytes UDP packets at every 20ms period and then they checked if all packets they sent were received well, and they used Wireshark program on the PC to check this, and they found some packets were lost.

They also found there was no issue in their same test on C6678, and this packet loss was only occurred on C665x.



Thanks and Best Regards,
SI.

S.I.,

"They have not modified example code, and they got similar results even when they tested with pre-built file". How they determine there are packet loss by the C6657? The wireshark can only prove packets sent from PC to C6657. Does 6657 respond to each packet received and send a packet back to PC? In this way they can find loss from Wireshark.

Please clarify how do they know C6657 has Rx packet loss? As long as my GbE didn't introduce packet loss, my setup should be OK. But to debug this, I may need a PC to EVM direct connection.

Regards, Eric

Hi Eric,

Yes. 6657 respond to each packet received and send a packet back to PC.
As I heard, the helloWorld example is the program which send back the packet it received.

Could you please explain why loss can be found from Wireshark?

Thanks and Best Regards,
SI.

S.I.,

Wireshark captured the packet traffic both ways. If you saw a packet sent from PC to C6657, but there is no reply from 6657 to PC, then the C6657 has a problem.

So, I reproduced the problem. Let me debug what happened, I might fix it if something easy. If not, I will open a ticket and let developer to fix it. 

Regards, Eric

S.I.,

I tracked in the working cases: packet Rx from PC---->EMAC statistics counter increments (0x02c0_8200 region)------>EMAC_RxServiceCheck----->LLIRxPacket---->IPRxPacket----->host application code-----> IPTxPacket---->LLITxPacket---->EMAC_TxServiceCheck---->Packet Tx to PC. This is the call flow. Also in the program there is two globals: ips and udps can be used to track IP/UDP packets statistics inside NDK stack.

In recreated several failures and debugged this, I saw two common symptoms:
1) Rx path is OK, IP/UDP Rx stat still increase in NDK. But NDK Tx fails. IPTxPacket() can't be hit when set a break point
2) Rx path fails totally, the EMAC statistics counter stopped increments. There is no packet received at EMAC at all.

This needs developer to look further. I opened a ticket:

https://cqweb.ext.ti.com/cqweb/main?command=GenerateMainFrame&service=CQ&schema=SDO-Web&contextid=SDOWP&entityID=SDOCM00120213&entityDefName=IncidentReport&username=readonly&password=readonly

Regards, Eric

 

Thanks Eric,

I'll waiting the result.

Thanks and Best Regards,
SI.

Hi Eric,

Is there any update on this?

Thanks and Best Regards,
SI.