UDP performance issue

Continuing the discussion from UDP issues and workarounds:

Hi,

Testing the Spark IP/UDP performance I have the same issue.
As far as I can test it, it has something to do with multiple UDP writes in the same UDP session.

The sketch below, with multiple writes (at least 3 but most of the time with 2) and no loop delay, kills the Core immediatelly (blue, green, red, ….) after flashing the code.

Increasing the delay between the UDP write session helps (or randomise the issue?).
However, reducing the UDP write to one with no delays seems to solve the problem.

Note also the a Udp.println(‘1’) generates 3 packets (‘1’+ 0x0a + 0x0d) which is a guaranty to crash the Core!

Please comment on the possible solution.

Robert

/*
Spark UDP write demo sketch
by @rrobinet1 29/08/2014

The remote socket (host IP address and UDP port) and local port have to be adapted
according to the user context.

Typical host configuration is obtained using net cat (nc).
To receive UDP data use the command:
nc -u -l
*/

// Local host socket
unsigned int localPort = 50000;
//Remote host socket
unsigned int remotePort = 55000;
IPAddress remoteIP (192, 168, 0, 100);

//Create UDP instance
UDP Udp;

void setup()
{
// Bind the UDP instance
while(!Udp.begin(localPort)); // Wait for socket binding
}

void loop()
{
// UDP Write to the remote socket
Udp.beginPacket(remoteIP, remotePort);
// Udp.write(‘1’); // 1st UDP PDU
// Udp.write(‘2’); // 2nd UDP PDU
// Udp.write(‘3’); // 3rd UDP PDU
// Udp.write (“The quick brown fox jumps over the lazy dog\r\n”); // A … long UDP packet
Udp.println(‘1’); // Println generates 3 UDP packets
Udp.endPacket();
// delay(10);
}

I think this is what you need, i cant take full credit… i just cut and pasted!

Its available as a library on my Git, https://github.com/Hootie81/DNSClient/blob/master/DNSClient/inc/myUDP.h

Add to your code:

#include "myUDP.h"

myUDP iUdp; //create an instance same as before but to myUDP
1 Like

What a strange answer!
YES I need to be able to send multiple UDP packets, YES I need to have a stable development platform with a stable IP suite (not asking me why its is catching or why it is hanging).

So YES this is not the platform I am looking for, thanks and goodbye
Robert

1 Like

Sorry i didnt make my self very clear, Im pretty sure with the current implementation in the core’s firmware each “write” is a new datagram… the end packet does nothing! (from the UDP issues and workarounds post)

it is not a single datagram that includes the beginPacket, write1, write2, write3…, endPacket

when you do a println() on the UDP it breaks it up into 3 datagrams as you say, sending so many datagrams so quickly it will probably hang quickly.

The code i linked above creates a buffer at the beginPacket, appends each write to the buffer and the buffer gets sent when endpacket() is called.

@rrobinet1 I’m only trying to help, I’m still learning myself.

I have sympathy with @rrobinet1. What needs fixing is the broken implementation of UDP (and all now acknowledge that, but it is difficult because TI screwed this up) but also what needs fixing is the supposedly Arduino-compatible interface to the UDP protocol provided here. That too is broken, and needs fixing, and if it is fixed by myUDP.h then that should become the default and the current not-Arduino-compatible interface should be discarded.

1 Like

Yes, there is a problem. In a nutshell:

  • UDP.write currently sends packets. It should never trigger a packet; rather, it should write to a buffer.
  • UDP.endPacket should send whatever is in the buffer in a single packet. (Currently, I’m not sure what it does other than track internal state.)

This means you will have to use your own buffer for now. It’s not hard to implement, but it’s a pain when you are expecting the cool behaviour the Spark docs describe.