Firstoff, I wrote the magic shaper with Dinesh's assistance because so
many people were asking for it, and I wanted to get a project to start
with to familiarize myself with FreeBSD. I used the wondershaper script
for Linux as my starting ground.
> 1) Why the 3 different "high priority upload" queues?
WonderShaper has three ;-) Seriously, that's why I started it that way.
Each queue has different weights. So, think of it as mission-critical,
urgent, and important. It let's you not classify a packet as bulk, but
not give it the highest priority.
> 2) Looking at the "m_Small Pkt Upload" rule, it seems that this would
> completely include the "m_TCP ACK Upload" rule, since the former appears
> higher in the list (hence making the separate TCP ACK rule redundant).
Correct. The m_Small Pkt Upload rule was added after the m_TCP ACK
rule, and I missed that one. I'll fix it in the next version.
> 3) I did some connection monitoring on a machine running BitTorrent, and I
> noticed that a good 50% of the connections from it aren't on the standard
> 6881-6999 port range. Given that I'm not trying to prohibit BitTorrent, but
> merely prevent it from slowing down other network connections unreasonably,
> I'm trying to find a reliable way of doing so.
> If I know the machine that's responsible for the BitTorrent traffic, can I
> define rules as follows:
> If | Proto | Source | Destination | Target
> WAN (out) | * | Cronus | * | P2P Upload
> WAN (in) | * | * | Cronus | P2P Download
> (sorry, I suck at ascii art, but you get the idea)
> If I'm on the right track, that *should* mean any traffic into/out of Cronus
> should go into the lowest priority queue?
Depends on where the rule is at in the list. If that rule is placed
right before the catch-all's, then any web type traffic should get
higher priority, and anything not classified will get put in the hated
queues. Watch out for things like sending/receiving email attachments,
etc., as those will slow down.
> Given high priority up/download are mainly for VPN, so let's assume only
> catch all and hated are in use: if a queue is completely unused, how is
> traffic distributed?
> Default magic shaper config for those is as follows:
> Upstream weights: catch-all (4), hated (1)
> Downstream weights: catch-all (40), hated (10)
> So, am I right in saying that given none of the high-priority queues are in
> use, for every 4 packets of "ordinary" traffic, one packet of "hated"
> traffic is allowed? If so, that means that 20% of outgoing traffic should be
> "hated". Is there any mileage in changing this by reducing the priority of
> the "high priority" queues in favour of increasing the priority of the
> general queue?
> i.e. High priority is redefined as weight=50, general has a weight=49, and
> hated has a weight=1.
> If my calculations are correct, that should mean that only 2% of outgoing
> traffic would be P2P.
It has been *so* long since I worked with the weights (and to be honest,
Dinesh had to explain it a few times to me), that I'll let someone else
answer the above. Be a good review for me :-)