Measuring network speed.

[wviperw]

I just transferred a number of mp3 files (2.21GB worth) from one computer on my network to another. I decided to test the 100mbps network speed, so it should give me a max rate of 12.5MB/s, right? Or at least a decent rate of 5MB/s or so. But I ended up calculating it at about 2.4MB/s which is quite poor for a 100mbps network.

1) Am I testing it right? I just did megabytes/time in seconds (2272/953)

2)Does the fact that I transferred mp3's have anything to do with the slow speed?

 

[cmetz]

Your tests have as variables the disk, memory, I/O, CPU, OS/filesystem, TCP, NIC, and network signalling for both hosts. That's not a good test.

If you want to test performance, first, go to and from a ramdisk, to get a lot of the disk issues out of the way.

Also, TCP uses something called slow start as part of how it discovers the capacity of a link for a connection. The consequence of this for performance is that small files never actually get up to full throttle before they're done. You need to use BIG files in order to get around this effect. Which is harder to fit in memory on each side.

What protocol did you use to transfer files? FTP? SMB? Different protocols have very different performance characteristics. FTP behaves as I said for TCP for large files, but each file is its own separate TCP connection, resetting the slow-start timer and also having to do some round-trip waits while the control connection does its thing and the new session's handshaking happens. SMB mostly doesn't have TCP's performance wierdnesses, but SMB... just plain sucks from a performance perspective.

 

[wviperw]

ermm... Well, I'm just doing a Windows->Windows transfer by c&p, so I'm not sure what "transfer" method you'd call that (tcp?).The thing about the variables was a good point though. I knew that these would be a part of it, but not THAT big of a part of it, but now I can see how they could be. And then the fact that it was mp3's looks like it did make a difference because it never had a chance to get to full speed.

 

[cmetz]

Ah, you're using mapped Windows drives, meaning SMB.

SMB sucks for performance. The protocol is seriously flawed. You can fix it incrementally but not fundamentally.

If you're trying to do serious file transfers between machines, try ftp or scp.

 

[JackMDS]

Some people consider the use of this free program as an agreed upon standard.

You have to install the main program on one computer, and a client on a second.

The program bypasses some if the trepidations mentioned by cmetz.

A FREE Utility for Network Troubleshooting from NetIQ!).

 

[gaidin123]

Though it is a poor judge of overall performance, if you are using windows XP, just drop into the task manager and watch the percentage utilization of your NIC. With large SMB transfers on my LAN the friendly little graph shows my 3com card (or the server end) to be maxxing out around 80-84% of 100Mbit which should equate to around 10MB/s. Just doing a test of a 689MB file copying from the server to my box XP showed 82-84% usage almost the entire time which should equate to around 67 seconds. In reality it took 74 seconds (as timed by my watch 🙂) which equates to 9.3MB/s~75Mbps.

After protocol overhead and tcp ramp up time the smb was actually a bit higher performing than I thought it would be (both of these boxes are pretty fast machines with the western digital 8MB drives).

iperf is another benchmark utility that I like though it may be outdated nowadays. You can specify the amount of traffic to transfer, or the length of time to blast packets at the server. It's a freeware client/server small command line DOS program (works in a windows command prompt with no problems however).

Gaidin