Dirk,
> Otherwise STP might do the job, although without hardware assist it won't
> perform that much better than TCP as far as CPU use and bandwidth are
> concerned (especially on 100baseT, which is slow enough that modern
> machines have no problems dealing with it).
It sounds like you are talking about a 1 Gb source and 100 Mb sinks.
In this case, you must be careful that you bound the ST block sizes
for your ST Write sequences so you don't overwhelm the available
elasticity buffering in your network infrastructure.
Put another way, if you try to send from 1 Gb source to 10 100 Mb
sinks, and you burst (your ST block size) 4 MB at a time, and your
switch can only absorb 1 MB, you will almost certainly end up with
almost 3 MB worth of data thrown on the floor. ST will retry, but it
will fail each and every time because it's retry granularity is an ST
block.
Put another way, ST doesn't do adaptive congestion avoidance.
You can solve this problem by tuning down your block sizes, but
smaller blocks means higher CPU overhead, and this still only works
well if the network is known to be operating in a steady state
(quiescent is nice). If there is an increase in traffic flow to one
of the 100 Mb hosts, you'll end up losing again.
In this case, you will have to use an ST block size of ~100 KB ( * 10
= 1MB). To hide latency on a per flow basis, you might also want to
have two outstanding CTSs, in which case you're talking about 50 KB
blocks.
The 10 * 100 Mb sources to 1 Gb sink works better, for the obvious
reason. In general, STP only works unconditionally well with equally
sized source and sink pipes and a non-blocking fabric.
Still, for all this, if you can get your traffic balanced right, STP
will probably be two decimal orders of magnitude more efficient than
TCP. This doesn't matter for the 100 Mb hosts, but it's very
significant for the 1 Gb host.
Steph
|