What is considered good or bad bandwidth for a GB LAN?

I ran the network tool 'IPerf" on 2 PC's that are connected by several GB Switches.  The results are pretty close every time I ran the test, please see below

G:\Downloads\Iperf\From_France\files>iperf.exe -c XXX.XXX.XXX.151
------------------------------------------------------------
Client connecting to XXX.XXX.XXX.151, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[  3] local XXX.XXX.XXX.151 port 64114 connected with XXX.XXX.XXX.151 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   719 MBytes   603 Mbits/sec

--------------------------------------------------------

My question is this acceptable for a GB switch network?  I suppose if you take 603 and divide into 719 that is 83%; but, I have no frame of reference.  I would think that the power of the computers make a difference as well; but, can someone explain to me:

Question1: What is considered good bandwidth results for a GB LAN connection?

Question2:  What is considered bad babdwidth results for a GB LAN connection?

Question3:  How can I make a definitive test using Iperf?  or any other utility?
LVL 1
PkafkasNetwork EngineerAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Martin MillerCTOCommented:
Question1: What is considered good bandwidth results for a GB LAN connection?

Your result of  greater 50% of the a 1Gbps line is GOOD


Question2:  What is considered bad bandwidth results for a GB LAN connection?

This is subjective to the traffic, number of competing connections.

Question3:  How can I make a definitive test using Iperf?  or any other utility?

Regardless of the utility, tests approaching link speed are good.
Dave BaldwinFixer of ProblemsCommented:
Good = 1000Mbits per second, Bad = anything else.  However... every method has overhead that in testing subtracts from that.  It is likely that your network is running at 1000Mbits per second point to point.  But TCP connections have handshake sequences every so often that do not show up as data that was transferred.  File operations will be even 'worse' because you have the directory operations that aren't included as data that was transferred.

You can't make a "definitive test" for all circumstances.  You can check other methods and see if you're getting what you expect.
nociSoftware EngineerCommented:
603 / 719  makes NO sense at all..... this might be a lot of comparing apples to banana's etc.
603 is a speed measure, 719 is a SIZE measure.  

line speeds are measured in bits per second (bps)  (lowercase b).  This is RAW line speed, all higher protocol overhead still needs to subtracted.
Sometimes transfers are measure in MB/s (Mega BYTES.second, capitabl B).   There's a number of bits / byte involved.
For synchronous connections it is safe to assume there are 8 bits / byte.  If bytes are mentioned as speed measure then there is also packet overhead... at least 40 bytes / packet. and packet sizes do differ, so one also needs to know the packetsize (MTU = packet inclusing overhead) to calculate this.

603/1000 ~ comes to 60% of line speed...
Now you are correct to assume that computer speed at both side is involved.
but also the number of connection point in between two stations. (ping will give you an estimate of latency).
fragmentation can influence transfers negatively,
after a certain amount of data is sent an ack is needed. (in your case 64KB). the window size. transmission will stop until the ack is in.
If disk files are involved, a 1Gbps network is faster that a IDE/USB2 disk bandwidth.

To get better speeds: did you try a larger window  (256KB)?

Another way to test is using a different tool:  netio  ( https://web.ars.de/netio/ )  (it can also test asynchrous sent packets, trying to flood networks) so it might give better raw statistics of pushing data in stead of round trip delays included in test restults.

btw, in your measured circumstances imho 603Mbps is not too shabby.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

PkafkasNetwork EngineerAuthor Commented:
Thank you everyone. My next question was going to be how to interpret the results from the iperf test.  But noci took care of that.

How may I increase the size of the "window" to 256KB in the iperf test?
nociSoftware EngineerCommented:
-w option?

I tried here with different window sizes.  Too large a window doesn;t help. 128KB gave best results (on my LAN).
One switch between 2 nodes. (-w 128K)
[  4]   1.00-2.00   sec   112 MBytes   940 Mbits/sec    0   88.4 KBytes      

-w 32K
[  4]   3.00-4.00   sec  66.6 MBytes   558 Mbits/sec    0   29.9 KBytes      

(Last column was the effective window size when ack was received).
with -w 256K there were too many retries, so some tunning on the kernel level might be required on my network.

also try udp in stead of tcp connection. Be sure to specify your want a 1Gpbs bandbidth though.
(UDP has no overhead like ack going back and forth)
PkafkasNetwork EngineerAuthor Commented:
It was stated that "603Mbps is not too shabby. "

May I ask what is considered bad?  Is it less than 50%, so less 500Mbps?
JustInCaseCommented:
Typical limitation for testing speed between 2 PCs via Gb network is HDD speed. If you are having SSDs on both  PCs than you can expect better result then above (up to 100Mb). Laptops HDDs are typically having write speed of 60-80MB (480-640Mb). The highest speed (speed limitation) in that case will be how fast HDD can write data to disk.
So, in that sense, network speed may not be limited only by throughput of network equipment, there are other limitation factors (including, and not limited to, bad cable quality, antivirus is scanning files and during scan slow down data transfer).
You can try both copying data in both directions, from PC1 to PC2 and from PC2 to PC1, depending on HDD speed and other limitation factors you can have different transfer speeds in both directions.
I tested gigabit network in my home few years back. PC1 had HDD, PC2 SSD. Copying 4Gb ISO image from PC1 to PC2 speed was around 110MB- write file to SSD (880Mb), in opposite direction speed was around 80MB - write file to HDD (640Mb).
nociSoftware EngineerCommented:
@pedrag:
iperf doesn't use a file transfer. So it is a correct statement / observation, albeit not relevant.

About 603Mbps being not too shabby meaning that there is room for improvement, but it might be the best attainable under current circumstances.
Q is how many switches in between the nodes.  If there is fragmentation of packets that causes a big overhead...

I forgot to mention the receiving statistics for the UDP test, which come down to:...
[  5]   2.00-3.00   sec  6.24 MBytes  52.4 Mbits/sec  0.074 ms  14181/14980 (95%)  
so huge packets loss on UDP packet re-assembly (Those are 8KB packets in MTU 1500 frames).  doesn't happen for TCP like this, unless the MTU is not the same along the path.
PkafkasNetwork EngineerAuthor Commented:
There were 2 64 - bit PC's connected through 2 x GB Ethernet switches.

Both - PCs have non-ssd drives.

I think that there most likely is not a problem with the ethernet; but, how can I be sure.
nociSoftware EngineerCommented:
traceroute?
ping times?

Those have been mentioned as "you need to determine latency as well"
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Network Analysis

From novice to tech pro — start learning today.