QUOTE(AlThePal @ Jul 12 2007, 05:08 AM) [snapback]56531[/snapback]
Most multi mode products give their maximum distance as 2km. The Moxa switches state 4-5km depending on the fibre used. I've used Moxa equipment for a number of years and have always found it to be excellent, and substantially cheaper than European alternatives.
My experience is with 1 Gbps multimode fiber. There are two different types of transceivers. I believe one is "LX" and the other is "FX" or something like that. At 1 Gbps, we found that the weaker version has a much lower range. At 100 Mbps, the range limitation certainly isn't there. At least the stuff we have is 62.5 micron, 850 nm. Once I hit about 500 meters into the plant, I had to use a repeater until we went to the more expensive transceivers. All of my transceivers are GBIC cards, which is a standard modular component as opposed to built-in transceivers.
If you put in single mode, you can go as fast and as far as you want. Telcos install it with repeater stations every 50-80 kilometers, so the range is effectively unlimited.
QUOTE
As you point out, I only have one master, so as far as I can work out IGMP (which would keep broadcast traffic to one part of the network) won't have any great effect.
With IGMP, you are supposed to have a router or some other sort of layer 3 device on your network that acts as more or less the "arbitrator" or "switchboard". Without it, IGMP defaults to broadcast mode. Nodes that are doing multicast send "join" type messages to the router. Switches that are doing IGMP snooping scan for the IGMP traffic and automatically restrict multicast traffic to only transmit on the appropriate ports. This is identical to the way that a switch learns the port map, except that it is a many-to-many map instead of a one-to-one map. On reboot, the switch is in broadcast mode and broadcasts packets to all ports from all ports. But it snoops the source addresses and the port it originates on, and stores it in a map. The next time it sees a packet destined for a MAC address that is in it's port map, it only transmits the packet to that specific port. IGMP snooping works the same way except that there can be multiple desination ports.
QUOTE
You mentioned about full duplex Ethernet being deterministic - this point has always confused me. Switches work by connecting one Ethernet device directly to another. However, if you have a network where basically you have one master (generally with one Ethernet port) and many slaves, only one slave can talk to the master at one time. Ethernet/IP uses multicast to send the data to the consumer(s) without the consumers having to ask for it - quite different to the classic serial command/response model. This means that slaves could be trying to send to the master at the same time, and so continually colliding and backing off - if effect you have a situation that is no different to using hubs instead of switches (although you still need intelligent switches to cope with a ring configuration).
Is this correct or does anyone know better?
Collisions are not the same as flow control. This is a misinterpretation of what is going on. Ethernet/IP is not going to fix this problem. Packets will not collide and back off.
In an Ethernet with one segment, regardless of how the hardware is implemented, all nodes are effectively wired together on a single wire. If any one node broadcasts, the others all receive it simultaneously. If any two nodes broadcast, both packets are destroyed and nobody receives them. The backoff/retransmit stuff makes the delay not only longer but also random.
In an Arcnet network (Controlnet is an implementation of Arcnet), one node on the network holds a "token". That is the only node that is allowed to broadcast. When the node releases the token, then the next node gets a turn. The token floats around the network, going from one node to the next according to their node numbers in order. Even if a node has nothing to do, the token must be passed on. This is as short as possible since nodes can "pass" the token simply by remaining silent.
This collision vs. token passing thing is what makes Ethernet "nondeterministic". If I knew exactly how much traffic was on the network and when, I still could not sit down with a calculator and paper and tell you exactly how much delay and throughput a given packet will experience. That is not the case with half-duplex Ethernet.
I can minimize this somewhat. If I put in switches operating at half duplex, then it means that each device is on a separate network segment. The only possibility of collision is if a device transmits at the same time that the switch attempts to transmit a packet to the device. However, the possibility of collision still exists.
With a switch-based network however, we can do full duplex Ethernet. In this mode, the transmit and receive lines are separate. Since there are two separate paths, a device can send and receive one packet simultaneously. There is NEVER a possibility of a collision any more because each direction on the wire is a single network segment with a single device on it. At this point, if I know the throughput of every device and every segment, and I know the delay on each device including switches, I can calculate the exact response time for every packet...I'm back to an Arcnet world.
What you are referring to is an entirely different problem. If the switch or the node or whatever is currently busy receiving another packet, the packet will go into a queue until there is time to handle it. There are various queue designs to handle arbitration from one queue to the next, but most systems use either some variation of RED (prominent on a lot of routers) or round-robin these days. If you exceed the bandwidth of any given part of the network on a temporary basis, the packets will be held in queues until the queues can be drained. If you do this continuously, eventually the packets will be destroyed because the queues overflow. This is not a collision. It's simply saturating the bandwidth and/or storage capacity of the network. It doesn't matter if you are using Ethernet, Arcnet, FDDI, or RS-485. The end result is the same no matter what network you use.
Ethernet/IP is sort of like doing a file transfer in a lot of ways, but this is somewhat different from conventional control network protocols. When you do a file transfer, you initially send out a request for a file. Then the file server starts transmitting a stream of packets until the file is done. There is only one request, but the response could be several gigabytes in size.
Most of the time, control networks only have one packet worth of data at a time. So there is one request packet, and one response. Ethernet/IP allows the requester to set up a single outstanding request where the response is received periodically and continuously, every time there's an update. The real bandwidth savings is in the fact that the responder also can respond ONLY when there's a change. So for instance temperature readings may not send another packet for several minutes.
Thus, Ethernet/IP by itself has nothing to do with collisions or bandwidth limitations, but you can still run into either one if you exceed your network capacity.