In another forum section I recently posted about the actual throughput as measured for the Ethernet shield, using a Mega2560. In a nutshell, without any changes to library code, you get around 15 KBytes per second. Changing the SPI clock from 4 MHZ to 8 MHZ bumps that up to about 20 KBytes per second. Eliminating any usage of the print() and println() functions makes a huge improvement, topping out around 70 KBytes per second. Note that these rates are based on measuring from the first byte of sent data to the last byte, and don't account for other program delays.
With these tweaks, maybe 70 KBytes per second is good enough. But in some situations, it would be nice if faster rates were possible? In an effort to evaluate the Arduino platform for some more extreme applications, faster Ethernet is a requirement for me, and it can be done with the right hardware.
The simplest approach is to use the Wiznet W5500 Ethernet chip, instead of the W5100. Although the W5100 is good, the SPI interface is pretty inefficient because it requires that a 16 bit address and 8 bit command be sent ahead of each data byte. The W5500 has cured that inefficiency by allowing data transfers to specify the address once, then follow with just data bytes afterword, automatically incrementing an internal hardware pointer, until the SS line is raised and the SPI transfer is ended. The W5100 is also about half the cost of the W5100, and comes in a smaller package.
Using the above best case benchmark, and an average buffer write of say, 10 bytes, the expected throughput should be comfortably above 200 KBytes per second. Just keep in mind, each buffer write becomes a single socket send command at the socket level. That means additional overhead associated with sending lots of little packets. Bigger buffers are always better whenever it is practical to do so.
I'm interested in pushing the limits even higher. Fast Ethernet transfers aren't necessary for HTTP client server stuff. They are good for streaming data, however. And if one wanted to stream data in both directions, faster Ethernet would be a necessity.
To go even faster, a faster SPI interface is needed. Now, the specification for this chip indicates a theoretical 80 MHZ SPI clock frequency, but a guaranteed frequency of 33.3 MHZ. Although not stated, I suspect that 33.33 MHZ is more of a guaranteed throughput kind of number for larger SPI transfers. Trying to design around an 80 MHZ clock can be quite challenging. 20 MHZ isn't so bad, and increasing a custom SPI interface from 8 MHZ to 20 MHZ would bump the estimated single buffer transfer speed into the 500 Kbyte/second range. That is a considerable increase in performance.
To be fair, these numbers are fairly raw. For example, the custom SPI interface would need to be loaded 8 bits at a time. Using a bit-banged approach and avoiding the standard library digital I/O calls, how fast can we wiggle bits? You would need to load new data every 10 processor clock cycles to run at that rate. That could probably be done for a single buffer transfer. But inline assembly code would quite likely be required in that part of the Ethernet library.
One other change for a faster Ethernet shield would be to implement the interrupt line for the W5500. When waiting for a socket connection, the current shield handles this through polling. For simple applications, this is quite fine. But eliminating the polling frees up clock cycles, which may be needed for other things.
Faster Ethernet has advantages. The faster you can get your data to or from the Ethernet chip, the faster it can move the data. This reduces time spent waiting, and increases the time available in your sketch to do other things. If you are bumping into limits on what you are able to do with the existing Ethernet shield, would you be interested in a faster one?