Hi,
We are using C6657 DSP with NDK Version :ndk_2_21_02_43, and encountered a problem, which needs clarification urgently,
since our customers ran into problems here! .if any help is appreciated.
Brief Description of the problem:
In our application we are continuously sending very small TCP Packets with 32 Byte to the DSP in 1ms intervals.
We encountered TCP retransmissions in about 10% of the packets, caused by a missing ACK from the NDK.
We used Wireshark for the analysis.
Since we implemented a HIL application, these retransmissions are a huge problem, because we cannot wait for the retransmission (~300ms retransmission timer).
Test Setup:
The test was conducted with direct connection between sender (PC) and receiver (DSP). No switches in between that could cause packet loss by collisions.
Observations:
When sending 32 Byte Packets, we see retransmissions.
We dug deeper into the NDK and saw CRC errors on the IP layer, but surprisingly no CRC errors on the physical layer (PHY and EMAC) => See attached statistics
We continuously increased the packet size to 320 Byte and the problem with the retransmissions suddenly disappeared.
Values between 32 Byte and 320 Byte had showed a continuous improvement, but CRC errors on the IP layer occurred nonetheless. No CRC errors on the physical layer (PHY and EMAC) like before
With a 320 Byte packet size there were more CRC errors on the IP layer and No CRC errors on the physical layer (PHY and EMAC) like before.
Just to clarify: We are running BER Tests on the electrical link on the MAC layer. The electrical link is fine.
Just to clarify: We ran the two tests for several hours with millions of packets. 320 Byte packets never caused a retransmission or CRC errors, while 32 Byte packets do in 10% of times.
Questions:
Is this a known issue?
Any ideas if we could fix that by a different configuration of the NDK?
Since we found a temporary workaround, is our approach to simply increase the packet size to 320 Byte a failsafe approach, that will work under all conditions?
Attachments:
Attached you find the statistics from the NDK info structures for both cases, 32 Byte (Bad case) and 320 Byte (Good Case)
Suspicious stats are marked.
Attachment #1: Bad case: 1000 Packets with 32 Bytes Payload:
TCP Statistics from TI NDK :
RcvTotal = 996
RcvShort = 0
RcvHdrSize = 0
RcvBadSum = 6 => CRC Errors
RcvDupPack = 0
RcvDupByte = 0
RcvPartDupPack = 0
RcvPartDupByte = 0
RcvAfterClose = 0
RcvAfterWinPack = 0
RcvAfterWinByte = 0
RcvWinProbe = 0
RcvDupAck = 0
RcvAckTooMuch = 0
RcvAckPack = 1
RcvAckByte = 1
RcvWinUpd = 0
RcvPack = 986
RcvByte = 32000
RcvOOPack = 0
RcvOOByte = 0
IP Statistics from TI NDK :
Total = 1589
Odropped = 0
Badsum = 0
Badhlen = 0
Badlen = 8 =Why? Because of CRC Errors?
Badoptions = 0
Badvers = 0
Forward = 0
Noproto = 0
Delivered = 1520
Cantforward = 0
CantforwardBA = 61
Expired = 0
Redirectsent = 0
Localout = 990
Localnoroute = 0
Reassembled = 0
Fragments = 0
Fragdropped = 0
Fragtimeout = 0
Fragmented = 0
Ofragments = 0
Cantfrag = 0
CacheHit = 0
CacheMiss = 1
Filtered = 0
Attachment #2: Good case: 1000 Packets with 320 Bytes Payload:
TCP Statistics from TI NDK:
RcvTotal = 1003
RcvShort = 0
RcvHdrSize = 0
RcvBadSum = 0 => No CRC Errors
RcvDupPack = 0
RcvDupByte = 0
RcvPartDupPack = 0
RcvPartDupByte = 0
RcvAfterClose = 0
RcvAfterWinPack = 0
RcvAfterWinByte = 0
RcvWinProbe = 0
RcvDupAck = 0
RcvAckTooMuch = 0
RcvAckPack = 1
RcvAckByte = 1
RcvWinUpd = 0
RcvPack = 1000
RcvByte = 320000
RcvOOPack = 0
RcvOOByte = 0
IP Statistics from TI NDK :
Total = 1436
Odropped = 0
Badsum = 0
Badhlen = 0
Badlen = 0 => Fine now
Badoptions = 0
Badvers = 0
Forward = 0
Noproto = 0
Delivered = 1410
Cantforward = 0
CantforwardBA = 26
Expired = 0
Redirectsent = 0
Localout = 1004
Localnoroute = 0
Reassembled = 0
Fragments = 0
Fragdropped = 0
Fragtimeout = 0
Fragmented = 0
Ofragments = 0
Cantfrag = 0
CacheHit = 0
CacheMiss = 1
Filtered = 0
