Bill Caroselli (Q-TPS) wrote:
I understand what he is talking about.
We use redundant networks on audio workstations. You can be playing audio
through the network, unplug one network and the audio keeps on playing.
Unplug the other network and the audio keeps on playing.
To other person:
QNX4 will favor the first network where a path exists to the destination
node for ALL traffic unless there is a detected failure on the first
network. Then and only then it will try the second network. IT DOES NOT
FLEET DOES LOAD BALANCE (hey my caps lock key does work
Why it wasn’t load-balancing for you, I don’t know, but we are using it
here for synchronizing redundant controllers. The load balancing can be
seen very clearly on our system, as the speed at which our controllers
scan I/O is a function of the size of the pipe they have to synchronize
through. If you set up a test where the controllers are updating
outputs rapidly, and then pull one of the redundant ethernet cables that
link the controllers, you can see the update rate of the controllers
drop, as the synchronization takes longer (due to only a single lan),
plug the cable back in and the update rate returns to normal. Of
course, in any of the applications that use the controllers we consider
the single lan update rate as the worst case scan time, the improved
speed in normal operation is simply a bonus.
In order to make use of the load balancing you must transfer data
asynchronously across the lan (since sending it synchronously leaves
your application blocked until it receives the reply - at which point
the the lan that you last sent on is obviously ready to accept data
again - in this way it might appear that one card is being favored).
Was your application using synchronous message passing ?
btw: FLEET stands for Fault-tolerant Load-balancing Extensible Efficient