Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If I have a bunch of computers on a 100 Mb/s switch with the matching NICS, does this mean that there can be a total of 100 Mb/s of traffic on the network at a time? So two separate pairs of computers will only be able to communicate at 50 Mb/s. (I understand that actually speeds will be much less than 100%)
If I have one switch with two vlans and/or subnets, will the 100 Mb be divided or shared?
If I have two switches on the same subnet/vlan how will the bandwidth work?
In general, the speed of a connection (to anything) is set by the hardware in the interface. This is a combination of the circuity, the protocol, and maybe the length of the cable between repeaters.
Look up the specs for---eg---:
regular ethernet
"gigabit" ehternet
USB-II
Firewire
SATA
.
.
etc.
These are all specs for interfaces---each one has a maximum data rate, regardless of how the data is multiplexed, switched, etc. before going thru the interface.
The thruput can be throttled at the server end of an ftp process, and it can be throttled by your ISP. (eg to get you to pay more for the higher speeds)
Yeah but if I have two computers on a 100 Mb/s switch with 100 Mb/s cards, and one is transferring to the other at a rate of 100 Mb/s, is the rest of the network at a standstill?
This all depends heavily on the hardware of your switch. When a switch is advertised to be a 100Mbs device all that is guaranteed is that your hosts can send data to the switch at a rate of 100Mbs. You are basically asking what is the bandwidth of the switching plane of the switch. I.e., how fast does the switch internally move data around. It could be anything. On nice high end (Cisco, Extreme, Juniper, etc) gear, the switching plane will have enough bandwidth so that every host sees full bandwidth between every other host at all times. For regular consumer gear, I suspect that it is much less, but I haven't seen any measurements done.
I used to do development on devices used to test just this kind of thing (Spirent, Ixia, and Agilent are the major players), but I never found the time to hook up my personal equipment to it and see how it performed. I always wanted to know who had the best switching plane.
To extend what cetialphav said, this is the difference
between a hub and a switch. A hub sends every packet everywhere,
so there would be 100Mbps total available. A switch only
send packets to the port that needs it. Any one ethernet cable
runs at 100Mbps. That is relevant to your third question:
> If I have two switches on the same subnet/vlan how will
> the bandwidth work?
Obviously, if the switches aren't connected the operate
completely independently, each with 100Mbps. Given that
they ARE connected, they are connected by a piece of ethernet
cable, and that cable runs at 100Mbps. Therefore the total
bandwidth of all traffic between the switches is 100Mbps,
hence the reason many switches have a single higher
bandwidth port for connecting to other switches.
As cetialphav mentioned, the connections inside of the
switch aren't made with ethernet cables, so there's no
telling what their switching rates may be and that's
what you second question depends on.
Bear in mind that data on a network isn't a continuous stream: the nature of ethernet is that all data is sent as packets, chunks of a few hundred bytes. Your NIC has to wait until the network is quiet before it can send a packet. When the first packet has gone the NIC has to wait for the network to be quiet again before it can send another, and it's quite possible for another NIC to have got in there first. Thus a single transaction on the network cannot monopolise the bandwidth.
What kind of switch are you asking about -- SOHO or professional? E.g., Linksys or a real Cisco?
I assume you are envisioning something like the following scenario:
If boxen A, B, C, & D are connected to switch S & all 5 are 100 Mb/s, can there be 2 simultaneous transfers through S at 100 Mb? Say a 1 GB transfer from A to B, plus a 1 GB transfer from C to D?
How hard would this be to set up & test?
Should I do it? ...
Also, IIRC, N-way switches are cheaper switches because they divide the 100Mb (or Gbit) switch N-ways, depending on how many devices are plugged in. ie: They are onyl capable of 100Mb/s total, not per-port.
To find out the true maximum throughput between say two computers hooked up to a switch or via a crossover cable do this:
ethstatus -i name of interface on receiving computer
on the transmitting computer do this(as root): ping -fs 65507 ip address of receiving computer.
!!!!!!!!!WARNING!!!!!!!
DO NOT ABUSE THIS COMMAND IT IS A FLOOD ATTACK! But used in this fashion it will tell you what the true maximum throughput is in MB/s
DO NOT USE this command in a production network as it WILL take everything that the network has to run this, and then some. The ethstatus command is also CPU intensive! ONLY do this for TESTING purposes ONLY!!! For accuracy anything that is using the network aka firefox, streaming radio, etc.... needs to be shut off.
Lastly take the number that is in MB/s and multiply that by 8 for 8 bits per byte. That way it will tell you a) the efficiency and b) how many Mb/s you are really getting on a 10/100/1000 Mb/s rated whatever These commands I utilized on Debian systems converted over to host-based routers via quagga, I do not know what the equivalents for Fedora or others are, although since it is all Linux I am sure, "We have the technology!" :P
FYI every resource I can find disagrees with laughingboy's comment
about N-way switches.
from computerlanguage.com:
Definition of: N-way
An Ethernet switch capability that automatically detects the speed and type of transmission on each port and adjusts the switch to accommodate it (10 Mbps, 100 Mbps, 1 Gbps; half or full duplex). All modern Ethernet switches are N-way.
N-way functionality was first developed by National Semiconductor in 1994.
3com.com says:
There are two main methods in the market for auto-negotiation, the
standard method (Also known as “Nway” signaling) and the “Trial and
Error” method , which toggles between 10 Mbps and 100 Mbps, till
there is a “Link” signal. The 7600 supports the standard IEEE
802.1u auto-negotiation (Nway).
The 7600 isn't a cheap switch which splits bandwidth. Nway, as used
by 3com, means the same as previous definition - standard autonegotiaton.
Cisco aso describes their switches, which are not cheap, as nway.
this is the difference between a hub and a switch.
That is the key statement in this thread, so I'll highlight it again (it looked buried).
Quote:
Originally Posted by brilyant
When the first packet has gone the NIC has to wait for the network to be quiet again before it can send another
That would be true if we were talking about hubs, but we're talking about switches, so it is wrong.
There is also "half duplex" vs. "full duplex". In full duplex signals can go in both directions at once over a single link. So a 100Mb link carries 100Mb in each direction simultaneously.
I expect there are some obscure exceptions, but switches normally permit full duplex and hubs normally don't.
So:
100Mb hub = A single 100Mb data flow at any given instant in one direction between one pair of end points.
100Mb switch = In theory as many simultaneous 100Mb data flows as there are end points on one switch (so each end point is both sending and receiving a 100Mb data flow). As you interconnect switches, you may reduce the number of simultaneous data flows below the total number of endpoints, and of course if one destination end point is the target of two or more source end points, those must share bandwidth.
One thing that seems to have been happening in this thread is that people feel that 100 Mbs is a data rate (or haven't made it clear that it isn't).
It is actually a signalling rate and not a data rate.
That is, if you look at the fastest rate that an individual bit can switch, it is a rate that could lead to 100 Mbs if were bits were packed as closely as they could be. brilyant mentioned one reason why this doesn't happen, but there are many and if, even on an otherwise quiet network network, you are getting more than half this 'theoretical' rate, you are doing well.
Obviously, as johnsfine mentioned, on a network arch with hubs rather than switches it is almost impossible in practical situations to get an otherwise quiet network because collision domains spread. And when you consider how CDMA works in arbitration (when one user has finished, other users have a go at capturing the next time slot on the network; if two users collide in their attempt, both back off by pseudo-random amounts of time), with hubs throughput falls off if you try to load the network the network heavily from multiple sources.
if, even on an otherwise quiet network network, you are getting more than half this 'theoretical' rate, you are doing well.
Assuming switches (100Mb hubs were always relatively rare and 10Mb hubs should have been discarded by now and aren't part of this discussion) I think you're wrong about that "half".
I don't know the exact overhead levels to a lightly loaded connection, but I'm pretty sure they're way less than half.
This OP included
Quote:
I understand that actually speeds will be much less than 100%
So we have just been discussing the relative speeds of multiple links through one switch vs. one link through that switch. We haven't discussed the actual rate of useful data you might get from a 100Mb link. Obviously it is less than 100%, but I'm pretty sure it is quite a bit more than 50% (assuming large packets).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.