|
Mac GeekeryGet your geek on. |
|
blog advertising is good for you
recent popular content
User login
|
e:leaf asks: QuestionSince the new Airport Extreme has come out, there have been all sorts of numbers flying about in different speed tests. As you almost certainly know, what Macworld or some random Joe may get in his tests are all but completely irrelevant to most other users simply because of ISP/bandwidth differences at different locales. It’s nice to see what Macworld has to say, but I would like to run my own tests once mine arrives so that I can accurately gauge any speed differences. I know how to go about doing an internet speed test (my favorite test is www.speakeasy.net/speedtest), but that too is right up there near useless when one considers that my download speeds are already maxed out at 10Mb/sec. What I want to do is have an accurate test so that I can gauge the speed increases (if any are to be had) with transfers across my LAN, without having to rely on the very untrusty “stopwatch” method. Is there a quick Applescript (or some other such code wizardry) that can be whipped up which will record transfer rates across my LAN? AnswerAh, now that’s a fun one. I do this often and use a variety of approaches depending on what’s at hand. First, start with a large file. There’s a ton of ways to make a large file, but the most user-friendly is to open Disk Utility and make a 1GB disk image (NOT sparse). People who are friends with Terminal might want to: $ dd if=/dev/zero of=big-file.bin bs=1g count=1 So, with your gigabyte file in hand, pick your transport method. You can turn on AFP, SMB, or FTP on the remote machine, or use SCP to send it over if you know how. It shouldn’t matter. But, alas, it does. For some, AFP and SMB are on-par with each other. For others, one is horribly slower than the other. You’ll need to test for yourself. FTP and SCP tend to be of an even speed no matter what, however you’ll need to use Terminal or a GUI client to use either. The curiously-named CyberDuck handles both protocols well and is free (as in desperate and clingy). Before you use your tool of choice to get it going, take a moment and pick one of the following methods of detecting instantaneous transfer rates:
Have it ready and displaying your network speed and then send the file down the pipe. Watch the tool’s transfer rate as you do it and you’ll see your true LAN speed. Related: Optimizing AirPort Connectivity
About Adam Knight
 Author Biography Adam Knight is one of the founders of Mac Geekery and is a geek at heart. Programmer by day, hacker by night, his daily life revolves around the Macintosh platform, which he has been a user and programmer for since the early days of System 7 when his LCII replaced his Apple //c. In-between tech jobs, he’s managed to learn the basics of any web hacker: PHP, MySQL, Perl, Apache, Linux, *BSD, and the intricacies of ./configure —prefix=~/bombshelter/. Today, codepoet is concentrating on blogging again, writing some software for the Mac by himself (including Notae) and for his company (such as Switchblade) and has a few other toys coming out soon. Bug him over AIM or email [link fixed]. |
Adam, I’m pretty sure that scp does on-the-fly compression, and if you have a 1gb file full of zeros it’s going to compress really well and give you an artificially high bandwidth number, depending on how you measure it.
Also I’m not entirely happy with the concept of transferring files around in order to measure network performance. You’re just as likely to measure the write performance of the target system’s disk if you’re not careful.
I currently swear by netperf (available through MacPorts), but have also used ttcp in the past. Either of these will provide accurate network performance benchmarks.
In this case, we’re testing a network that is slower than the drive, so it’s not a big concern if neither host is under load.
While SCP can compress, it does not by default and requires the -C flag to do so. And while that would certainly alter the statistics SCP gives you, it wouldn’t change the numbers in the mentioned tools at all, which are looking at the raw bitstream on the device.
to avoid measuring disk read/write perfomance instead of network bandwith (most probably not the case with wifi):
dd if=/dev/zero bs=1k count=1024k | ssh target “cat > /dev/null”
or something similar will do the trick
- IF something somewhere compresses the data down the path this will report really, really high bandwidth
– /dev/urandom may be used in such cases (though i am not sure how this is implemented on mac osx)
the best app for tcp/ip and all network stuff is ipnetmonitorX, it has a link rate test that is killer, check it out;-)
dd is fantastic, though for something like this i’d just use mkfile, which had easier to remember syntax:
$ mkfile 1g big-file.bin
also, props on mentioning sar!