Alright, so I now officially don't like Iperf anymore. The romance is over.
I started checking out Iperf a few months ago. It's like a voltometer for network bandwidth. It kind of works like Ping.
You need two copies of it running, on two different computers on a network. You set one up in server mode "iperf -s" and then you set the other up in client mode "iperf -c servercomputer.mynetwork.com" and they saturate the network between themselves and report the amount of bandwidth there.
By default, the client just connects, tests bandwidth silently for ten seconds, and then reports the average speed and quits. The server hangs around waiting for more client requests. With switches you can make it work like ping, where it tests bandwidth continually and gives you running reports every second.
This sounded great for our wireless networking projects, as we could use iperf to very practically test what happens to a wireless connection as you move around antennaes and do site surveys. I mean we have signal strength meters, and little doodads that tell us what speed the connection is negotiated at, 2Mbps vs 11 Mbps etc, but there's nothing as final as really seeing how many bits fit down the pipe.
The problem was that it turned out that iperf behaves very badly in smarmy network conditions. You can run it on a wired network, no problem.. pull your ethernet cable, no problem and it says "0.. 0.. 0..", plug it back in, no sweat.. but there is something swampy about being in the very fringes of a wireless network that makes iperf go bonkers. The client, in a windows dos-box, crashes and sometimes freezes up so bad that "end process" can't even touch it. Sometimes it just gets stuck so that even when you're back in wireless sunshine it won't report anything to you.. but you can kill it and start over and all is well.
Even worse is that, under the same conditions, the server itself crashes nearly as often. (luckily the server doesn't seem to freeze or lock hard :) We've confirmed this on Windows, Linux, and FreeBSD boxes.
We need this to work for site surveys where our salesperson can carry around a tablet and not need to intervene much. So I got fed up and wrote a replacement. It took all of 11 hours of tinkering to produce a 1.5k perl script that beats iperf (for our needs) all hollow.
The perl app is the client, while the server is an xinetd socket linked to "yes". "yes" is a prog that spits out "y\n" forever, or anything else you ask it too.. it's great for saturating networks; and for being repetitively affirmative.
iperf can allegedly test both the up and the down bandwidth — which I haven't been able to confirm — but for most wireless connections I mess with up and down always end up congruent. My app tests down only. Also iperf can test exotic things like UDP, which we don't use. My app only does tcp. My app uses netcat, so I could UDP were I in a bad mood, but I'm not. :)
My app, unlike iperf, appears to survive even the smarmiest of network conditions. It will never crash, lock up or die and neither will it's server process. That success took up most of my tinkering time — it used to have minor lock ups alla time. Additionally, it spits out pretty bars which visually confirm bandwidth er.. width.. and a spinny dealybob that spins at the speed the app receives bits at.. so you'll know the instant you step behind an object that impacts your connectivity. I can even set the poll refresh to fractional seconds (hurray for Time::HiRes).
The pretty bandwidth bars and the spinning doohickey are also done in box-drawing ansi chars for the greatest visibility, since it can be hard to see what's going on on a laptop or a tablet PC when you're walking around out in the bright sunlight.
Altogether I'ma proud of my new, cute li'l app and glad to be able to create something "new under the sun" given the veracity of yon world full o' open source coders. :)
Posted by jesse at June 25, 2004 04:50 AMOh yeah, almost forgot to mention. If you wanna see/use da script, email me and I'll pass a copy to you. If you have a laptop with a wireless card it gets addictive :)
You'll also want a server running to feed you the bits. If you have xinetd (comes standard with linux), or maybe it would work with inetd as well, set up "yes" to listen on a port and you'll be fine. Any way you can make a machine immediately scream bits at any client that connects on a port would make a fine server for this script.