Since my home router and wireless access points all run Linux, I can play all kinds of sadistic games with routing, tunneling, traffic shaping, etc.
One of the experiments I did a while back was creating a "satellite Internet connection from halfway around the globe" simulator on a dedicated wireless SSID. Basically, I created a new SSID and used Linux's traffic control/queueing discipline stuff to limit that SSID's outbound throughput to 32 kbps, limit inbound throughput to 64 kbps, add 900 milliseconds of latency on sent and received packets, and randomly drop 4% of packets in/out. Very, very few sites were even remotely usable. It was astonishing.
I think one of the most useful products that could ever be created for web developers is a "world Internet simulator" box that sits between your computer and its Internet connection. (Maybe it plugs into your existing wireless router and creates a new wireless network.) It would have a web interface that shows you a map of the world. You click a country, and the simulator performs rate shaping, latency insertion, and packet loss matching the averages for whatever country you clicked. Then devs can feel the pain of people accessing their websites from other countries.
(Thinking about this for a minute, it could probably be done for about $30 using one of those tiny 802.11n travel routers and a custom OpenWRT build. It would just be a matter of getting the per-country data. Hmmmmm...)
OS X has a handy GUI tool called the Network Link Conditioner, which lets you easily set up simulated network conditions. The inbuilt profiles are a bit optimistic, I find, but it's easy to add more.
It's just tc or the BSD equivalent under the hood, but it's point and click and easy to turn off.
Neat -- I'm still on OS X 10.6 and didn't know about this. Thanks for the pointer!
I guess the advantage of a dedicated pain box is that any device, regardless of operating system, could use it. Network Link Conditioner (and the two pieces of software mentioned so far by siblings of your comment) are all OS X-specific. (That's another webdev gripe for another day.)
Speaking to OS X specifically, it's dead-easy to set a machine up to route traffic, so you can use the Mac as a pain box, in this sense. Of course, the same largely applies to any OS these days.
Oh that looks promising and it`s easier than my current solution. Thank you! For years I used the following small note saved on my mac to perform bandwidth tests of my application.
I have bash aliases for various levels of ipfw throttling, but I've ended up using other programs because 768k/s with no latency seems to load some kinds of sites disturbingly close to the speed they load if I let the bandwidth back up to its 18mbit/s normal speed, which I think has to do with latency. Lots of the Mac OS standalone programs that do this kind of thing, like Link Conditioner or Speed Limit, add configurable latency to requests as well.
The reason Link Conditioner is 10.7 and up is that it's using pf[0] internally. The man page for pfctl[1] is pretty easy to read after you start to get the basics of how pf works. Be careful applying examples you find online though. Last I heard, OS X's version of pf is slightly newer that FreeBSDs, and moderately behind OpenBSDs.
There's a tampering proxy named Charles that allows this sort of thing on the fly, and for mobile devices if you so wish. I find it absolutely indispensable for finding the heavier parts of websites I'm working on.
Brilliant idea! I've been traveling through less developed parts of the world and it is painfully obvious when you encounter a site that wasn't tested on anything less than broadband.
Also, the Facebook app on my iPhone (pre-rewrite) would almost always cause me to lose my edge connection to the cell tower when launched in certain parts of Indonesia.
One of the experiments I did a while back was creating a "satellite Internet connection from halfway around the globe" simulator on a dedicated wireless SSID. Basically, I created a new SSID and used Linux's traffic control/queueing discipline stuff to limit that SSID's outbound throughput to 32 kbps, limit inbound throughput to 64 kbps, add 900 milliseconds of latency on sent and received packets, and randomly drop 4% of packets in/out. Very, very few sites were even remotely usable. It was astonishing.
I think one of the most useful products that could ever be created for web developers is a "world Internet simulator" box that sits between your computer and its Internet connection. (Maybe it plugs into your existing wireless router and creates a new wireless network.) It would have a web interface that shows you a map of the world. You click a country, and the simulator performs rate shaping, latency insertion, and packet loss matching the averages for whatever country you clicked. Then devs can feel the pain of people accessing their websites from other countries.
(Thinking about this for a minute, it could probably be done for about $30 using one of those tiny 802.11n travel routers and a custom OpenWRT build. It would just be a matter of getting the per-country data. Hmmmmm...)