Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In automation and control, it is commonly stated that ethernet can't be used as a bus because it is not real time capable due to packet collisions. If important control packets collide, they often can't keep the hard real time conditions needed for control.

But what if I have a single point to point connection with Ethernet, no switch in between? To be more precise, I have an FPGA board with a giga-Ethernet port that is connected directly to my control PC. I think the benefits of giga Ethernet over CAN or USB for a p2p connection are huge, especially for high sampling rates and lots of data generation on the FPGA board.

Am I correct that with a point to point connection there can't be any packet collisions and therefore a real time environment is given even with ethernet?

Thanks in advance! ~fsb

share|improve this question

migrated from Jan 9 '11 at 9:52

This question came from our site for professional and enthusiast programmers.

Define real-time :)

On a more serious note, even though there will be no collisions, there is no guarantee that packets will not be lost (for instance due to implementation bugs). I've seen this happen.

share|improve this answer

To the first part, full-duplex mode is possible for point to point links in later Ethernet standards. You can usually force an Ethernet card into full duplex mode to avoid the possibility that the auto-negotiation scheme would set it to half duplex.

But I wouldn't say "therefore a real time environment is given" without a look at the behaviour of all the other parts of the system (flow control, NIC performance, busses, operating systems, etc.) And inversely, even if your Ethernet network is half-duplex, if you can customize all of the systems and software on the network, you can still impose your own time slice scheme to avoid collisions: =)

share|improve this answer

Correct - there can't be any "collision" on P2P Ethernet (only on half duplex medium such as coax). The problem then with your real-time expectations are pushed upwards at the OS firmware level.

share|improve this answer
It depends on the hardware. I have seen collisions on 10BaseT and 100BaseT, where (at least) one end had sufficient cross-bleed between the Rx and Tx elements. I'd say "there can't be any collisions for full-duplex point-to-point ethernet". – Vatine Jan 9 '11 at 10:18
that's what I am saying: half duplex --> collisions. 10BaseT/100Base-T in half duplex mode --> potential for collisions. – jldupont Jan 10 '11 at 15:03
Coax has nothing to do with the collision. The important part is the buffering in the switch. – Magellan Aug 23 '14 at 6:02
@magellan you might want to look-up your reference. Start with… – jldupont Aug 24 '14 at 12:05
I assure you, collisions occur in twisted pair media as well. Your answer is worded quite poorly and may give inexperienced the impression that the elimination of collisions is inherent in the media, not simply due to the connection being built. – Magellan Aug 24 '14 at 14:19

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.