Faster ethernet data transfer time than 2ms

[Hungry_Pete]

Dear all,

I'm using labview 7.1 based on a standard laptop communicating with a LabVIEW real time maching running the standard real time operating system. The two machines are connected through a dedication ethernet switch  (rated to 1Gbs), and both have ethernet cards (rated at 100Mbs or greater).

The aim of my project is to have a fast distributed control scheme going. This basically means that small amounts of sensor data have to be transferred very quickly between the two machines. The aim is to then scale this to have more machines on the network.

I use a UDP data transfer method, using the standard labview UDP read and UDP write vis.

I would like to acheive a major frame rate of around 500Hz. The problem I have restricting me with this is the speed of the ethernet connection. It would appear that the vi wrtes to buffer instantaneously, but it is taking as much as 2-3ms for the data package to be sent and received by the other machine. This is a ridiculously long amount of time. I'm sending approximately 100bytes, so the time on the network should be 0.01ms. This would suggest the time delay is in the reading or writing of the data from the Ethernet card over the PCI bus to the program.

Does anyone know why its taking so long? Do the UDP read vis only check the ethernet hardware every ms? I've taken great care to ensure that this is not a synchronisation or timing problem and I am certain it is not that. 

I could really do with making this data transfer quicker as it is clearly the slowest part of the control loop. If anyone has come across this before and found a solution I would be grateful to know about it. I'm really hoping that I won't have to write something low-level in C or anything like that and try and integrate it with the code I have.

Many thanks,

Pete

[Ben]

I'm not sure if the Naegal Algorithm applies to UDP but you may want to check that out.

UDP can be faster than TCP/IP but it is "lossy" meaning that there is no guarente that the data is actually recieved, only sent.

For TCP/IP the packet size can make a lot of differnece in transfer rates. I believe it was somewhere arounf 65K bytes is optimum packet size.

Re: adding more nodes.

Ethernet is CDMA Carrier Detect Multiple Access (?) meaning that multiple nodes use the same wire by first

1) Check for carrier to see if anyone esle is talking

2) If nobody talking then start talking

3) Listen to what is said and determine if it was garbled (collisiotn detect)

4) If collistion detected execute a random wait time then retry.

So...

As you add transmitting nodes the bandwidth effectively decreases.

Ben

[Hungry_Pete]

Thanks for your response Ben,

I understand UDP is a lossy method and that ethernet is a CDMA method rather than a collision avoidance method. With careful timing mechanisms in software system wide, it is possible to use ethernet as a collision avoidance mechanism rather than collision detection to make it deterministic and appropriate for distributed control. The bandwidth only decreases if you allow collisions via poor timing control of message - and this is not the problem I am experiencing.

I've also tried using TCP/IP instead of UDP with mixed success, but had it working at similar speeds. Most packets are being received fine so its not a data loss or garbled data problem.

If anything, I had to stop the Naegal Algorithm from working, as I need to send small amounts of data quickly, rather than waiting to fill a packet.

I have set up my system on a dedicated network with just these two computers attached (as mentioned) so I know there are no other data messages are there for it to collide with. The bus is free until one node wants to send a message. Even with nothing else on the bus, and no collisions occuring, the speed of transfer is still around 2ms and I would like to know why this is.

Many thanks,

Pete

[unclebump]

Fastest communication that I can think of for ethernet would be the I/O scanner option that is used with modbus tcp and modicon plc's. The I/O devices are placed on an ethernet network with the plc. Once configured properly, the communication just happens. I'm still looking for an update rate. It must be extremely fast, because we used to do this with input cards wired right to the plc's. Now it can be done over an ethernet network. My guess is that 2ms is really pushing it without buffering some data.

Interesting modbus tcp document here.

http://iatips.com/docs/nov2003_modbus_driver.pdf

http://www.softplc.com/guideselect.php

Possibly an add-on ethernet card.

http://www.systerra.de/documents/WOD-DRL-EIO-PCU.pdf

http://www.ixxat.com/download/wp210-0003_real-time_industrial_ethernet.pdf

You might want to look at Sercos III and Ethercat communication protocols.

Message Edited by unclebump on 02-23-2009 07:27 AM

[unclebump]

Finally found some hard numbers for data transfer rates. From this website. http://www.intellicom.se/ModbusTCP_overview.shtml

Performance from a MODBUS TCP/IP system
The performance basically depends on the network and the hardware. If you are running MODBUS® TCP/IP over the Internet, you won't get better than typical Internet response times. However, for communicating for debug and maintenance purposes, this may be perfectly adequate and save you from having to catch a plane or go to site on a Sunday morning!

For a high-performance Intranet with high-speed Ethernet switches to guarantee performance, the situation is completely different.

In theory MODBUS® TCP/IP carries data at up to 250/(250+70+70) or about 60% efficiency when transferring registers in bulk, and since 10 Base T Ethernet carries about 1.25 Mbytes/sec raw, the theoretical throughput is:
1.25M / 2 * 60% = 360000 registers per second and the 100 Base T speed is 10 x greater.

This assumes that you are using devices that can service Ethernet as fast as bandwidth is available.
Practical tests carried out by Schneider Automation using a MOMENTUMTM Ethernet PLC with Ethernet I/O demonstrated that up to 4000 I/O bases could be scanned per second, each I/O base having up to 16 12-bit analog I/O or 32 discrete I/O. Four bases could be updated in one millisecond. While this is below the theoretical limit calculated above, it must be remembered that the tested device was running with a lowly 80186 CPU running at 50Mhertz with an effective computing power of 3 MIPS (compared to the 700 MIPS of a 500MHz Pentium). Also, these results are nevertheless faster than the proprietary I/O scan methods used to date.

As low-end CPU's get cheaper, Momentum-type devices will chase the theoretical limit, although they'll never reach it because the limit will be continually pushed further away with 1 Gigabit Ethernet, 10 Gigabit Ethernet, etc. This is in contrast to other field-buses which are inherently stuck at one speed

[unclebump]

http://www.beckhoff.com/download/press/2003/usa/Ethernet_for_Control_and_Automation.pdf

[MichaelBeier]

Please have a look at

http://www.boschrexroth.com/business_units/brc/subwebsites/product_catalogue/en/steuerungskomponente... and

http://www.boschrexroth.com/business_units/brc/subwebsites/product_catalogue/en/steuerungskomponente...

for fast SERCOS III I/Os.