Pages: [1]   Go Down
Author Topic: Faster Ethernet Anyone?  (Read 518 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Newbie
*
Karma: 1
Posts: 16
Engineering Jack of all trades. Owner of a company that provides repair and calibration services for data acquisition products from a former employer. Looking to design a new series of data acquisition products using the Arduino platform.
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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?

Logged

SF Bay Area (USA)
Offline Offline
Tesla Member
***
Karma: 106
Posts: 6367
Strongly opinionated, but not official!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I remember when I was really happy to bump FTP performance from about 70kbps to 300kbps on the 3Mbps ethernet (yeah, those are all lower-case "b" for bits.)  It seems that much before that, 56kbps was about the max link speed anyway, so no one had really noticed how slow the internet code was :-)

Quote
would you be interested in a faster [ethernet]?
I dunno.  I'd rather have a board that had a better overall design for networking.  If it's going to use SPI, it should at least have DMA for it's SPI interfaces.  (some XMEGA chips can do that, I think.)  Overall speed is probably less interesting than "overhead"; I have to generate the data I'm sending somehow...

Did you investigate using the parallel interface mode of the W5100 ?  That seems more natural than putting a custom SPI controller in front of the SPI interface.  You could even consider using a more intensive parallel interface to some other ethernet controller (say, like a Yun with higher speed interconnect between the ARM and AVR.)

There are only so many "fixes" you can make to an AVR-based networking device before you have to ask yourself "why was I not using a Raspberry Pi or BeagleBone Black, again?"  (or even: connect up the Ethernet on a Due-like design...)
Logged

Offline Offline
Newbie
*
Karma: 1
Posts: 16
Engineering Jack of all trades. Owner of a company that provides repair and calibration services for data acquisition products from a former employer. Looking to design a new series of data acquisition products using the Arduino platform.
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

The parallel interface on the W5100 would certainly be better, but that would require using the external memory access capability of the Mega2560. The expansion interface I am designing will open the door to doing 8 bit I/O. And I have left hooks in place for a DMA controller.  I agree that DMA solves a number of overhead issues. I've used that in the past on other products with embedded micro-processors. Having a couple of DMA channels to handle communication and signal output or input really simplified things nicely.

Custom SPI dedicated solely to the W5500 will fit in a 44 pin CPLD with a cost of $1.18. It is the easiest way of cranking up the SPI speed and the easiest way of getting faster data transfers. Plus, anytime I see a newer version of an IC costing half as much as a prior version, I begin to wonder about obsolescence issues. I've just seen it happen often enough. Anyway, this is one option that is compatible with the existing Arduino hardware, and only requires minor changes in the Ethernet library. I would definitely utilize the interrupt capabilities of the W5500 for this one.

Now, if one were to use the expansion shield that I am developing as an I/O interface for a different version of a fast Ethernet card, that opens up some interesting doors, especially once the DMA controller is designed. That allows DMA transfers to be set up between Ethernet and expansion memory. And those transfers are not limited to 2 MBytes/Sec. Based on the specs for the W5500, it looks like 4 MBytes/Sec. is a guaranteed transfer rate. Of course, you are limited to transferring no more than what is currently available in the W5500 transmit or receive buffers. But filling up a buffer in a little over 2mS is pretty attractive.  smiley



Logged

Global Moderator
Netherlands
Offline Offline
Shannon Member
*****
Karma: 168
Posts: 12428
In theory there is no difference between theory and practice, however in practice there are many...
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I have done some optimizations of the print library last year (together with some others) that really improved the printing of numbers including floats substantially. Should work for the ethernet shield too.

- http://forum.arduino.cc/index.php?topic=179111 - (warning long thread ahead)
- http://forum.arduino.cc/index.php?topic=167414.0 - (warning ^2 even longer thread ahead)

If you use the print.cpp and print.h posted at the end (replace in the core file) you can test it on the net.

(have no ethershield free to test myself)
Logged

Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

Offline Offline
Newbie
*
Karma: 1
Posts: 16
Engineering Jack of all trades. Owner of a company that provides repair and calibration services for data acquisition products from a former employer. Looking to design a new series of data acquisition products using the Arduino platform.
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I would be happy to run some tests with these libraries and see how they perform.
Logged

Global Moderator
Netherlands
Offline Offline
Shannon Member
*****
Karma: 168
Posts: 12428
In theory there is no difference between theory and practice, however in practice there are many...
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

attached my print.cpp and print.h
you need to rename the print.cpp and print.h in the core  and place these there.

you need also to put the fastmath.h in the core folder
(core == e.g. C:\Program Files (x86)\arduino-1.0.4\hardware\arduino\cores\arduino)

* Print.zip (6.97 KB - downloaded 7 times.)
Logged

Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

Pages: [1]   Go Up
Jump to: