Ian Marchak wrote:
<SNIP>
> If you are running a 10Mb 4 port hub, you'll probably never get more
> than 2.5 megabits of xfer no matter what you do. A hub divides the
> total bandwidth (10Mb/s in your case) between all the ports evenly. A
> 10Mb/s switch on the other hand allocates 10Mb/s **per port**.
This is a very common misconception regarding how hubs (and for that matter switches)
work.
A hub does NO subdivide the available bandwidth between the ports, that is the
function of a
TDM (time divisional multiplexor). What a HUB does is broadcast all data it sees to
every port,
because it has no knowledge of where the destination for any of the data may be. This
is only
an issue if multiple ports are trying to transmit at the same time, in which case you
will see
collisions. If you have an Internet link with 3Mb capacity connected to one of the
ports, then
you are NEVER going to be causing any problems for the hub, only local transfers will
produce
enough network traffic to overload the hub.
What a switch does is "learn" what MAC addresses are connected to each port, and
"intelligently" create unique paths between all the ports that need to communicate
with each
other.
So for example, if you have a four port 10 Mb switch and the machine on port 1 is
"talking" to
port 2, and port 3 is talking to port 4, then the switch will create connections
between those
ports at full 10 Mb speed, whereas a hub will simply (re)broadcast all data it sees on
every
port. So to get every port running at 2.5Mb, then you would need to have all four ports
attempting to transmit that amount of data each.
There is also the situation where a switch is put in to "speed up" a bottleneck, e.g.
everyone
routes out of a WAN link (such as the internet) a switch is not going to be much use
here as
all data is being bottlenecked through one port (the WAN link), so the sum total of the
download speed cannot exceed the speed of that one port.
In summary, switches only help when you have multiple machines all wanting to "talk"
to each
other, not when ever port wants to "talk" to just one.
<SNIP>
> I suspect that .wav performance would be quite choppy, due to the fact
> that you are trying to stream/play files that have file sizes best
> estimated in ten's of megs...quite a challenge for a 2.5 Mb/s pipe.
The size of the file has no bearing on it's choppyness or otherwise. You sound file
could be
gigabytes in size; as long as you have enough bandwidth for the compressed stream, and
your
latency is constant then you should have no problems. Playing sound files encoded for
256Kbit
on a 3Mbit link should work fine if your latency stays constant. Playing sound file
encoded for
256Kbit on a 128Kbit link on the other hand will stink.
In addition, if you latency on the link is varying dramatically, this will cause
choppyness.
3Mbit of bandwidth in this scenario is of no use if you latency is bouncing all over
the place,
as sound (and video, typing, anything interactive really) does not cope with
variability in
latency. High latency is OK (although not desirable), as long as it's constant. I've
quite
happily ran Voice over IP (VOIP) on links with a 800ms latency, as long as the latency
was
constant (ish).
<SNIP>
> --
> Linux SxS [http://members.home.net/linuxsteps/]
> _______________________________________________
> http://linux.nf -- [EMAIL PROTECTED]
> Archives, Subscribe, Unsubscribe, Digest, Etc
>->http://linux.nf/mailman/listinfo/linux-users
_______________________________________________
http://linux.nf -- [EMAIL PROTECTED]
Archives, Subscribe, Unsubscribe, Digest, Etc
->http://linux.nf/mailman/listinfo/linux-users
