The Wonder Shaper

Back in 2002, Bert Hubert <ahu@ds9a.nl> attempted to create the holy grail. A tool that would handle traffic through a router with these characteristics:

The Result

The result was the Wondershaper — and it worked great when a fast internet connection worked at 200kbps. He got good ping times even when max'ing out the line with high traffic.

Before, without wondershaper, while uploading:
round-trip min/avg/max = 2041.4/2332.1/2427.6 ms  <== Extremely high ping times - 2300msec is 2.3 seconds!

After, with wondershaper, during 220kbit/s upload:
round-trip min/avg/max = 15.7/51.8/79.9 ms        <== Slightly higher times - 51msec is a twentieth of a second

The Downsides of Wondershaper

Although it worked well in the day, Wondershaper had a number of fixed constants that meant that it would limit the line speed, even when the internet connection was considerably faster.

In addition, there has been a tremendous amount of research in shaping traffic in the intervening decade, so there are better techniques (like fq_codel, pie, etc) that perform even better.

Finally, the original Wondershaper simply doesn't take into account newer technologies, such as voice or video chat, gaming, larger MTU's, PPPoE, ATM, IPv6, etc. See, for example, Dave Täht's Wondershaper Must Die essay (2013), where he writes:

At the time wondershaper was developed, DSL MTUs were typically 584 bytes and encapsulation-aware techniques that compensated for ATM and PPPoE didn't exist. An entire masters thesis got written by Jesper Brouer on fixing htb to work right with ATM framing and the code landed in the kernel in 2005. http://www.adsl-optimizer.dk/

Wondershaper was pretty optimal at 800kbit down 220 up, in an age of IW2 web pages averaging in size of 70k, coexisting with ssh traffic and voip, in 2002. It didn't scale up then, and doesn't work well at all now, at any bandwidth.

What can be done?

Wondershaper — as wonderful as it was in its day — needs to be replaced. Several "next generation" or "version 2" replacements have been proposed, but it appears that they're just patching the original. These projects miss out on a lot of the new research into packet queueing and minimizing latency.

As of mid-2018, there are solutions available. Those projects use active queue management such as fq_codel, cake, PIE, or other queue disciplines to manage the bottleneck link and allocate a fair share of the capacity to each flow of traffic running through the link. These sites offer examples of modern traffic shaping:

Finally there many test tools for measuring latency and bandwidth reliably to see if changes to filters and shapers have made an improvement. The Quick Test for BufferBloat tells about tools that indicate whether your connection is bloated. It also mentions other tools for measuring performance and latency.

Links to the outdated Wondershaper

For historical purposes, here are links to the earlier Wondershaper:

Wondershaper by bert hubert <ahu@ds9a.nl> © Copyright 2002, Licensed under the GPL.
Originally part of the Linux Advanced Routing & Shaping HOWTO
Requires Linux 2.4 & higher.

If you get an error in the last two lines of the script, try this version of iproute instead: ftp://ftp.inr.ac.ru/ip-routing/iproute2-2.4.7-now-ss010824.tar.gz. (local mirror)

Google
W3C Validation