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
Regards
@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
Hello @htibosch , I am facing same issue with FreeRTOS-TCP-4.0.0 with single socket but when I am running tuning tool I am seeing spuriouse retransmissions I have tried Window properties case also Can you please suggest me How issue resolved
I would need to see a PCAP of the TCP connections.
In my experience, most retransmissions are caused by the fact that timeouts are set to short, so it is like inpatient behaviour.
So if you want, zip a PCAP file and post it here.
I believe the new post is relevant to this discussion. Perhaps it would be more appropriate and organized if we could continue the conversation within that thread, consolidating all related points and discussions in one place.
It is also important to point out that retransmissions are not erratic scenarios by themselves but a crucial part of the fabric that makes TCP a reliable protocol. At times packets DO get lost or delayed simply due to the underlying infrastructure, so I wouldn’t worry too much about occassional retransmissions as long as the overall performance is acceptable. Note that even if you WERE to eliminate all of them in your lab environment, very likely in the field they will come back, without a customer ever noticing.
2 Likes