I'm using a sample UDP program to time reading a packet and I get around 12ms per 1k chars. I've had similar results with Uno. I got Due (and R3 ethernet shield) hoping the bottleneck in reading data was the processor speed but it seems unchanged. Is there a way to speed it up? Maybe upcoming ethernet board? Or Wi-Fi?
My arudino is controlling xmas lighting in remote location and is controlled by computer program. USB or serial cord, even a very long one, is not very practical.
I could be wrong, but I think there is a general speed limitation overall sending UDP packets. I think more or less the UDP protocol itself will be the limiting factor. Much like how TCP/IP is slower than UDP because of handshaking, etc.. you cannot get around that speed limitation.
SO, I think the limiting factor for UDP speed is the network protocol itself.
what are you doing with UDP? Currently I'm working on fleshing out a UDP protocol for a lighting controller, so I would be curious as to what you're up to. 
network speed will depend on the chip on the Ether shield and SPI speeds. The older w5100 ethernet module doesn't have a burst read/write mode so software has to do extra SPI transfers for each byte transferred. On the UNO, with SPI at 4MHz, I measured data rate of only 0.38mbs (megabits/second) for the W5100, whereas in burst mode (e.g. for w5200), I got 2.6mbs. Running the SPI at 8 MHz, I got .46/3.8 mbs (w5100/w5200).
For the leaflabs maple here are results for W5200, with different SPI speeds and using DMA with SPI
clock(MHz) SPI SPI+DMA
1.125 .7 mbs .9mbs
2.25 1.3mbs 1.8
4.5 1.6mbs 3.3
9 1.9mbs 5.5
18 1.9mbs 7.8
I haven't had a chance to perform DUE W5200 tests ....
UDP is capable of near wire speeds (for 10mbs and 100mbs ethers) from big-computer network controllers, but it can be an unreliable protocol over the Internet (packets can arrive out of order, duplicated, lost, or with errors).
I'm talking about specifically time to read the message from Udp. Something like this:
int time = micros();
Udp.read(...);
time = micros() - time;
This produces ~12000 per 1024 bytes. I don't think it's anywhere near hitting protocol limitations. As far as burst mode, etc, I'm not familiar with it and will look into it. But what I did see was that there seems to be some kind of buffer in the shield, so shield can accept packets pretty quickly. However, I need a sustained transfer rates. Since it's animating the lights, it's constantly running. So what was happening is the first few packets would be ok but then the buffer would get overrun.
As to what I actually do with it, it's a controller for GE ColorEffects G-35 lights. The program takes advantage of simultaneous bank write commands to write to up to 8 light strings at the same time, instead of writing 1 at a time. All the animation logic is done on the computer though as I find it much easier to just change the code and restart the program than having to run to the basement, reprogram arduino and run back every time I need to test something. And animations could be very tedious to debug.
My arduino code is here (although as is it won't compile with Due): https://github.com/firstone/GECEWriter
My pc code is here: GitHub - firstone/latic: Lights Animation Controller for GECELights
I'm not familiar with the exact details of the shield you are using, but the W5100 ether module typically can buffer 3 or 4 1K byte packets at close to wire speeds, but the interface to the UNO is via a much slower SPI, so if your SPI can't keep up, UDP packets will be dropped in the ether module. If you want sustained, lossless UDP, you will have to throttle down your remote transmitting device to run at the much slower SPI speeds. You can experiment with various delays between packets on your remote transmitter to see what works on your receiving Arduino. TCP might be a better choice (just as slow or slower) but it adapts to available bandwidth and is reliable.
I realize all of this and that's what I do. But I'd like to increase the speed. Which brings me right back to my original question - is there anything I can do to overcome this SPI bottleneck? Perhaps some other shield?
Also, does SPI depend to the processor speed at all? I thought it might but Due seems to read the data just as slowly as Uno. Sorry if it's a silly question - I'm more of a software than hardware guy.
Check the specs on the Ether device on your shield. I assume it's the wiznet W5100, and its SPI speed will be the limiting factor. I have a standalone W5200 and its SPI speeds are better (see Maple results in my table in earlier post in this thread), though I had to hack in DMA/SPI to get the best results on the Maple. (It's on my TODO list for DUE). The processor on the DUE has a builtin in Ether controller, but you'll have to wait for another kind of Arduino board that breaks those Ether IOs out -- and then you will need a lot of code/memory to do the TCP/IP protocols ... which is why the wiznet critters are attractive.
Just for the record, I ran some W5200 tests on the DUE with SPI and SPI+DMA, maple and DUE results are in wizperf.txt at
firstone,
All of the Ethernet shields from Arduino, including the latest R3 shield use the WIZnet 5100. This chip is quite old and due to the way it was constructed the SPI speed is very slow resulting in what I would describe as just utterly terrible performance.
One of my first sketches was to output a JPEG over http stored on a SD card plugged into the Arduino Ethernet R3. A 62 KB JPEG took over 3 seconds for the Arduino UNO with the shield to send the data to the browser which I timed using a Firefox add-on called Firebug. The performance was very slow, it almost reminded me of dialup days or when I first used an ISDN line.
It's going to take quite some time for another Due compatible board to come out that breaks out the SAM3X8E pins and allows you to hook up an external PHY and additional time for someone to develop the code to run a TCP/IP stack.
mantoui,
I have several WIZnet 5200 and even some WIZnet 5300 chips in the mail as well as the integrated WIZ820io which contains a MagJack and the W5200 chip. Once I receive them, I would be happy to run your benchmarks posted and confirm your findings. If what your benchmarks show is true, we may finally be able to get acceptable Ethernet performance out of an Arduino platform running these newer chips from WIZnet.