Recommendation requird for NIC

What do you mean by deterministic? IP is fundamentally "best efforts", and Ethernet is subject to statistical delays due to collisions. TCP is dependant on IP. I suspect you may be asking for something innately impossible.

--
"If you want to post a followup via groups.google.com, don't use
  the broken "Reply" link at the bottom of the article.  Click on
  "show options" at the top of the article, then click on the
  "Reply" at the bottom of the article headers." - Keith Thompson
More details at:

At what level of precision: seconds, milliseconds, microseconds?

"Very deterministic" and "TCP/IP over Ethernet" don't mix. If you need deterministic behaviour, CSMA/CD is exactly the kind of multi-master network protocol you do *not* want. IP doesn't change anything about that, whereas TCP introduces even *more* non-determinism into the communication's timing --- that's why networked multi-player games and audio/video streaming services typically use UDP instead of TCP.

No. You need something else than Ethernet. The internal network of a

*good* Ethernet switch running a private network or this application only may do, but that could be hard to control. Sooner or later some smart guy will decide that a real switch is too expensive for this smallish network, and "optimize" it away.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Deterministic communication and TCP/IP do not match.

You either have a reliable but non-deterministic communication such as TC/IP or deterministic but unreliable (such as UDP). If you need deterministic communication, the easiest way would be to use UDP and plan what to do when occasional frames are missing (e.g. hold the previous value or interpolate).

By using a dedicates 10/100baseT network with switches (not hubs) and assigning a single station as the master polling system and rest as slaves, quite good performance is possible.

Windows or Linux without a real time extension is not going to be very deterministic.

In the late 1990's some Ethernet cards had very bad drivers hogging the CPU for extended periods of time, thus destroying the performance of the already bad OS timing, but I have not heard of such problems in recent years.

You should definitively use a dedicated network card and network for your application, but "industrial NIC" is likely just a different connectors and/or better protection. The situation is different if e.g. Ethernet Powerlink is used, but this requires special chips at each slave.

Paul

I read a whitepaper some time ago, where the author developed a low level NIC driver (For ECOS If I recall correftly), that enables deterministic communications using ethernet hardware. The low-level driver ensured that raw packets are only sent at specific time intervals. Some of these timeslots are then allocated to specific processes which can then communicate with very deterministic timing. The traditional TCP/IP stack then get allocated the unused time slots. This of course only works when all devices connected to the network uses a similar low-level driver.

Also look at IEEE 1588 Precision Time Protocol. The IEEE 1588 precision time protocol (PTP) provides a standard method to synchronize devices on a network with submicrosecond precision.

Regards Anton Erasmus

If you need a deterministic timing, you should not use Ethernet. The packet timeslot allocation will fail after the very first hub in the route of the packet. The way to accomplish more or less deterministic timing (using the standard equipment) is implementing a software PLL and deep buffers.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

Deterministic comms is possible using ethernet hardware IF certain constraints are adhered to. For a point to point link using special low level drivers, one can get deterministic timing. Whether using ethernet is actually cost effective, once all the constraints are factored in is of course higly debatable. Using a more appropriate technology is probably more cost effective at the end of the day. I have used arcnet quite succesfully where the required data rate was not too high.

Regards Anton Erasmus

Ethernet hardware is OK, but you should not use CSMA/CD, but handle the arbitration differently.

This is only a problem as long as you rely on CSMA/CD.

Deep buffers and deterministic timing does not match very well.

This also depends on the operating system latencies. Assuming you are querying node X for data and system X needs to perform a task switch to build the response message and start sending it, the node OS needs to be deterministic and also have a very short latencies (to avoid degrading the bus average throughput). One way around this is that node X knows all possible queries and periodically builds all possible responses and stores in the driver space. When a query arrives, the interrupt service routine simply starts sending the requested ready built frame, thus keeping the latency low.

This also applies to multiple node networks, provided that there is only one master.

Ethernet hardware is available from multiple sources and is cheap. In

10/100/1000BaseT network is connection between two devices is a separate transmission line. However, with shared medium busses, such as CANbus or Profibus-DP, connecting multiple nodes into a single transmission line can be quite critical due to branch length limitations and connector quality, since all connectors are in series. The connector quality issue can be quite critical in industrial applications with not so clean environment and a lot of vibrations.

Ethernet is usable for deterministic systems as long as you do not use CSMA/CD and TCP/IP.

Paul