UDP delays my Sketch by 2 seconds if there is a network problem. SOLVED

I noticed an odd thing with my UDP sketch. The sketch sends UDPs command to a second UNO. When both the local and the remote Unos 'see' each over the network my sketch runs very quickly.

My UDP code I use is similar to the the SendReceive UDP example:

Udp.beginPacket(Udp.RemoteUnoIP(), Udp.remotePort());
Udp.write(DataCommands);
Udp.endPacket();

As I said if the network connection is working, the sketch sails through this section of the code and the command happens with typical network delays of a few milliseconds.

When I was working on my sketch with no network connection, as the code got to this UDP routine, it took about 2 seconds or so to run. Obviously there is some handshaking taking place between the network and the UDP messaging that stalls if the UDP/network fails. While UDP is a broadcast connectionless type protocol something must delay the routine if it doesn't complete properly. I then connected my Uno to the network so that it saw IP (but it couldn't 'see' the remote Uno as I didn't have it on the LAN). Even with the local Uno having IP the delay was still there.

Does anyone know why the UDP code is waiting? When it stalls, I can see the LED on my Ethernet sheild winking 3 or 4 times during the 2 second stall time. Maybe it is doing some sort of retry loop?

I suspect the sender is making an ARP request to find the physical address associated with the destination IP address, and this is timing out when the destination is not reachable.

What I forgot to ask is there anything I can add to my sketch to ignore the network status so that it will run with no delays regardless of my LAN connection or the availability of the remote UNO?

It is probably closer to 1.6 seconds. I can get that down to 200ms.

// add this to the includes
#include <utility/w5100.h>

   // in setup() after Ethernet.begin(), call this function.
   W5100.setRetransmissionCount(1);

Wow! Thanks works great! Thank you so much.

SurferTim:
It is probably closer to 1.6 seconds. I can get that down to 200ms.

// add this to the includes

#include <utility/w5100.h>

// in setup() after Ethernet.begin(), call this function.
   W5100.setRetransmissionCount(1);

yes, i've been doing some "fixing" to the UDP code, and saw the default rety count on the W5100 is set at 8, and 200ms each try. thus giving 1600ms timeouts.

i'm still trying to fix the issue with buffer overflows and keeping a decent count of the data in the buffer of the chip. :frowning: all I can say dont push any large packets at the chip at any great speed.