TCP/IP stack produces spuriouse retransmissions when using multiple sockets

Hello @Stonebull, I’m wondering if there is any news? Did you find a workable solution?

If not, you may want to send me an email so we can work together to find the cause.

My email address is unchanged: hein [at] htibosch [dot] net


@htibosch Sorry for my late reply, this is due to not being able to track down the real cause for the issue.
I’ll summarise what worked so far:

  • Disabling windowing all together #define ipconfigUSE_TCP_WIN ( 0 )
  • Disabling the topografy discovery protocols in windows

What I tried so far that did not help:

  • Increase the ARP cache size to 32 #define ipconfigARP_CACHE_ENTRIES ( 32 )
  • Change the window size to small / big size
  • Increase the number of descriptors
  • Try with/without a switch in between
  • Change optimization level of compiler

The problem is I do not really know how to debug the issue.

When stepping through the IP stack code while the number of descriptors is decreasing fast, I felt like the packages causing the drop were ARPs - which led me to believe that there are too many ARP broadcasts in the network and in turn, to disable the windows topology discovery services.

This seemed to help, but I still don’t really know if the ARP packages are really the source of the problem. Is the TCP stack really not capable of processing these requests fast enough to handle two sockets streaming data in the simultaniously? Especially since on wireshark the number of ARPs was not exessive (like 3x second).

That’s a very kind offer, I really appreciate your commitment regarding my problem. Although I don’t know what else to try. For now I’ll stick with disabling the windowing feature to be able to carry on. If I find some more insights to the problem I’ll happily come back to your offer and share what I found!

@RAc Thanks for your reply, it really looks like the Xilinx SDK (which is Eclipse-based) is responsible for generating those UDP packets!

1 Like