Clarification of Answer by
maniac-ga
on
02 Aug 2003 12:22 PDT
Hello Traderjunky,
Hmm. There could be a number of factors that can affect the results.
As I noted before, a modern PC should be able to keep a 100 Mbit
Ethernet fully utilizied (or close to that). I am including a few more
references at the end that show that kind of result. However, you are
not seeing that kind of performance, so some other factor must apply.
Some factors that can affect the results (reduce peak performance)
include:
- operating system overhead. For example, if the OS overhead to
initiate a transfer is 1 msec, then you will be limited to less than
1000 messages per second. To send 100 Mbytes in that one second, you
have to use 100 Kbyte blocks.
- other traffic. In an ideal situation, you would have an idle,
interface between the two systems. In the real world, other traffic
will interfere with the messages being measured.
- switching overhead. In an ideal situation, you would have a direct
connection between the two systems. In the real world, each switch and
router between the two systems will add latency to each and every
message. This may be a significant factor with some network protocols.
- protocol "rules". Using TCP/IP (the protocol used most often on the
Internet) as an example, there are "fairness" rules that require you
to send a little data, wait for acknowlegement, send more data, wait,
send even more data, wait and repeat until you hit the limit of the
connection between the two systems. This "slow start" is documented in
http://www.faqs.org/rfcs/rfc2001.html
along with other congestion avoidance algorithms.
- multi path effects. On a local network, this is not a problem, but
can be caused when there are two or more links connecting two systems.
This is caused by the arrival of packets "out of order" at the
destination. When this occurs, the congestion avoidance algorithms are
triggered, which will slow your transfers.
- small block / small message effects. If you use small blocks, the
total OS overhead will be far larger than with large blocks. In the
same way, small messages will require a connection to be started and
stopped each time and reduce performance.
- bottlenecks. Your test / application may be limited by the amount
of free memory or speed of disks (and not the network interface rate).
- "tuning" effects. The operating system may have some settings that
need to be adjusted to get the peak performance from your system.
Fixing this is usally an iterative process, make a change - run the
test, and repeat.
- other factors. As a couple of the netpipe results show, the
performance may vary in odd ways with block size. It is not clear what
the cause is, but may be related to data being copied to align
buffers.
Several more references follow to include:
- benchmark tools / some analysis
- tests of switches
- tests of 100 Mbit network interfaces
Odd - another Russian site with good links to benchmark tools.
http://www.benchmarkhq.ru/english.html?/be_net.html
Scroll down to "Netbench", hosted at
http://www.etestinglabs.com/benchmarks/netbench/netbench.asp
to get a file server / client application to measure performance
yourself. There are a number of other tools referenced as well.
For a general explanation of how NetBench is used by PC Magazine,
http://www.pcmag.com/print_article/0,3048,a=4408,00.asp
and scroll down to "Benchmark Tests: Business Servers". It notes that
the machines were substantially the same yet two products (HP, Dell)
performed more poorly than the others. They reloaded Windows 2000 and
did some other tuning to bring these machines in line with the others.
A series of benchmark tests of switches. If you select the
"Performance Results", note the almost 8 to 1 range of latency, though
most are closely bunched next to the best performers.
http://www.pcmag.com/print_article/0,3048,a=17628,00.asp
Performance results showing > 80 Mbit/sec on a 100 Mbit/sec Ethernet
include:
800 Mhz Pentium III, on board Intel Ethernet interface
http://www.acl.lanl.gov/plan9/netpipe/i82557.html
A variety of dual processor machines (1.4 to 2.8 Ghz CPUs); note the
odd slow downs with some block sizes.
http://www.hpc-design.com/reports/smp-interface/smp-interface.html
Another set of dual processor results (1 Ghz each); this does not have
the odd slow downs of the previous results
http://www.plogic.com/bps/bps-logs/index.html
A comparison of a variety of Ethernet cards on slower PC's (400 Mhz
and 166 Mhz). They also tested some "channel bonded" cases where two
or more Ethernet connections are used in parallel.
http://www.hpc.sfu.ca/bugaboo/nic-test.html
There are a number of other references available. Search phrases
include
netpipe performance results
Windows 2000 XP network performance results
Windows 2000 XP network benchmarks
--Maniac
,
0 Comments
)