Chun Wong wrote:
<snip>
Now somewhere in there is the culprit for slowing things down. I have been
using ftp get on large files to do the measuring: Is there a better method ?
Thanks
Chun,
Yes, try iperf to do performance testing. Even better, you want to
perform several (think multiple threads) in parallel. Even multiple
wgets on large files will perform much better.
Some of the things that will limit you in the current setup are:
1- nail up the interface speeds and duplex. Always a good idea given a
commodity switch (the SMC), or any switch for that matter.
2- the SMC switch. I presume it's a store and forward switch (each frame
is received in full, stored in memory, then forwarded). Higher
performance switches are "cut through" in which the header is read,
destination port is determined, and the packet is "started out" the
second port before the tail end of the packet is finished arriving at
the input port.
3- ftp. ftp is likely the worst test out there, and if you could graph
it in real time, you'll see a variety of issues, from the TCP sawtooth
effect (when packets start to drop, tcp, depending on what OS is
involved, will downrate the speed by 33-50% and try to ramp up again to
max speed), and having a less than efficient control channel (in proper
ftp, not passive) on another tcp port doesn't actually help. Lots of
places in the code where things slow down. Contrast that to http clients
being multithread and a lot more efficient. (ftp was designed for off
hours bulk transfer). Contrast this to a true streaming protocol which
uses UDP for transport, and a seperate tcp channel for control. Much faster.
4- vmware. well, it's a fake interface emulated on decent hardware.
'nuff said? Not terrible, but 3-4x the code and no direct access to the
network hardware or stack itself. My quick test (same application
code, same machine, same destination) cut performance "a lot" going
through vmware.
5- via chipset. Ok, not super, but workable. With similar hardware
(intel pro 100 nic cards) I used to get a typical 8-10MBps through a
cheapo store and forward switch (similar broadcom chipset to the SMC).
6- tcp stack settings. TCP window sizes, etc. Most by default are 10Mbps
friendly (that's bits/sec not bytes) especially in microsoft windows and
need some help for either higher latency (think cable/dsl) or higher
speed networks. Performance can sometimes double with a properly setup
client and server.
Hmmm,
Hope some of that helps. :-)
cheers,
andy
