UDP send 'stalled' until another UDP packet received
Ethernet Chips
No replies yet. Be the first to reply.
Join the discussion.
Ethernet Chips
No replies yet. Be the first to reply.
Join the discussion.
Share projects and connect with makers.
Joined before the site update? first.
New to WIZnet Makers?
We sent a verification link to your address. Open it to activate your account, then log in.
Accounts from this email provider are reviewed by an administrator after verification. Approval usually takes one business day.
Already have an account?
Enter your email address. If it belongs to an account, we'll send a link to set a new password. Members who joined before the site update use this to set their password.
If an account uses that address, we sent a link to set a new password. The link works once and expires in 30 minutes.
Know your password?
Need an account?
RE: UDP send 'stalled' until another UDP packet received
by Eugeny ·
Why do you think something is “stuck”? May it happen the original request was discarded by the W5500 (e.g. due to RX buffer overflow) or in software (due problems in data format)? You must match packets you see sent from the ‘host’ to the ones appearing on the wire and the ones displayed in the diag window of W5500 driving processor, and back to host.
At best you put marker into the packet to definitely identify what packet you get reply for (original request packet or retry request packet).
RE: RE: UDP send 'stalled' until another UDP packet received
by LowLatency ·
The reply time of 85us is indicative of the original reply data already being inside the WS chip. To get a reply though the entire cycle (wire time + ws to rp + rp processing + rp to ws + wire time) has never been below 500us.
It does not look like the packets were ‘lost’: there are 2 replies being returned after the ‘retry’ message is sent. One after ~85us (the one ‘stuck’ from the original msg?) and another after ~1-2ms later (normal round trip through the rp).
Here is Wireshark data from the host for a ‘retry’ event (highlighted) plus 2 ‘normal’ transactions (before/after the highlights). The host is at 192.168.0.20, the ws/rp board is at 192.168.0.50. There are not other devices on this network segment.
packet 1918 is a normal request, packet 1919 is the ws/rp reply in 509us (2nd column)
packet 1920 is a request, there was no response after 10ms, packet 1921 is the retry packet.
packet 1922 is received 83us after the retry (proposed ‘original stuck reply’ packet in the ws?)
packet 1933 is received 1.8ms later (nominal processing for full trip through the rp, response to the retry packet?)
packets 1924/195 shows a following ‘normal’ transaction 2 ms later, 853us for full round trip through the rp.
RE: UDP send 'stalled' until another UDP packet received
by Eugeny ·
The data you provide is insufficient. It is not possible to prove or disprove, in other words troubleshoot the problem. In addition to Wireshark log, you also need to show the logs of processor with microsecond timestamps of executing the SEND command to the involved socket.
RE: UDP send 'stalled' until another UDP packet received
by LowLatency ·
Agreed, having a log of the send timing would provide a more complete picture and I’ll work on producing that log. However, it seems unlikely that anything other than the ws chip can get data back out on the wire in 80us considering all the other replies involving the rp2040 are normally in the 500-1500us range.
I just completed running a test setup for 23hrs, 3.1M send/reply transactions, with only 289 ‘retry’ events. Whatever is going on has a very low percentage rate but happens on average every 5 mins.
Thanks for looking and providing suggestions!
RE: UDP send 'stalled' until another UDP packet received
by LowLatency ·
Due to other factors, I will not be able to provide further information for a couple of weeks. I will provide the requested logs asap.