Re: PF cluestick please - low priority queue spills over into normal queue
On Fri, Jan 8, 2010 at 7:09 PM, Tom Murphy wrote: > Aaron - > > Not sure if this has been mentioned yet, but maybe you need to > match the inbound traffic so that the related traffic going back > out will fall into the proper queue? > > e.g. > > pass in on $wired_if to $chechemaru queued wired_lo > > I've found with BitTorrent, Soulseek and other P2P-like things, you need > to match the incoming packets as well as they set up related connections > (states) back out. > > Tom > > Thanks to all who answered. In my efforts to get this working someone pointed me to a lovely little program that comes with transmission that allows you to control the web interface via the command line. I now use this tool on the seedbox to schedule the changes in transfer speed, scheduled by at. I figured I would do most of my dl'ing via BT and any time I do otherwise would be once in a blue moon. Thanks again -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
Re: PF cluestick please - low priority queue spills over into normal queue
Aaron - Not sure if this has been mentioned yet, but maybe you need to match the inbound traffic so that the related traffic going back out will fall into the proper queue? e.g. pass in on $wired_if to $chechemaru queued wired_lo I've found with BitTorrent, Soulseek and other P2P-like things, you need to match the incoming packets as well as they set up related connections (states) back out. Tom
Re: PF cluestick please - low priority queue spills over into normal queue
On Thu, Jan 7, 2010 at 10:13 AM, Robert wrote:
> On Thu, 7 Jan 2010 09:47:45 +1100
> Aaron Mason wrote:
>
>> altq on $wired_if cbq bandwidth 54Mb queue { wired_hi, wired_norm,
>
> Without taking anything else into account:
> wireless G network ... That 54Mb limit is too high.
> You should first reduce it by the overhead
> and then take some more off for good measure, about 10%.
>
> That "and some more" is explained in the FAQ or the the manpage, iirc.
>
> - Robert
>
On that note, it doesn't seem like my wireless card (Atheros
AR2413-based miniPCI card) is actually operating at 11g:
ath0: flags=8863 mtu 1500
lladdr (redacted)
priority: 4
groups: wlan egress
media: IEEE802.11 autoselect (DS11 mode 11b)
status: active
ieee80211: nwid (redacted) chan (redacted) bssid (redacted)%
wpapsk wpaprotos wpa1,wpa2 wpaakms psk wpaciphers
tkip,ccmp wpagroupcipher tkip
inet 192.168.1.5 netmask 0xff00 broadcast 192.168.1.255
inet6 fe80::211:f5ff:fea7:abe1%ath0 prefixlen 64 scopeid 0x1
So we're talking about 9mbit here. Not that it matters, my ADSL2+
connection only gets to 6mbit. So keeping the 178Kbps for the low
priority queue and splitting the remainder down the middle leaves
~4Mbit for the norm and hi queues.
I've made the change to better reflect what my wireless link allows,
and I'm still getting the same problems. This is all on OpenBSD
4.6-release, by the way.
--
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse
Re: PF cluestick please - low priority queue spills over into normal queue
On Thu, 7 Jan 2010 09:47:45 +1100
Aaron Mason wrote:
> altq on $wired_if cbq bandwidth 54Mb queue { wired_hi, wired_norm,
Without taking anything else into account:
wireless G network ... That 54Mb limit is too high.
You should first reduce it by the overhead
and then take some more off for good measure, about 10%.
That "and some more" is explained in the FAQ or the the manpage, iirc.
- Robert
Re: PF cluestick please - low priority queue spills over into normal queue
On Thu, Jan 7, 2010 at 5:09 AM, Calomel Org wrote:
> Aaron,
>
> When you say, "seem to spill over into the normal queue" do you mean
> the bittor queue is borrowing bandwidth from the total amount of
> bandwidth available?
No, what I mean is when the low priority queue fills up, it seems to
find a way to use the normal priority queue.
>
> You may need to set a limit on the bittor queue if you want to limit
> its bandwidth. The OpenBSD Faq says, CBQ queues are arranged in an
> hierarchical manner. At the top of the hierarchy is the root queue
> which defines the total amount of bandwidth available. Child queues
> are created under the root queue, each of which can be assigned some
> portion of the root queue's bandwidth. For example, queues might be
> defined as follows:
>
> Root Queue (2Mbps)
> Queue A (1Mbps)
> Queue B (500Kbps)
> Queue C (500Kbps)
As indicated by my pf.conf, this is already done. Hence my confusion
and frustration:
hi_bw = "33Mb"
norm_bw = "20Mb"
lo_bw = "178415b"
altq on $wired_if cbq bandwidth 54Mb queue { wired_hi, wired_norm, wired_lo }
queue wired_hi bandwidth $hi_bw priority 2
queue wired_norm bandwidth $norm_bw cbq(default) priority 3
queue wired_lo bandwidth $lo_bw priority 4
I see the queue wired_lo queue fill up, then I look at the queues in
systat and see traffic going through the norm queue as well, and
nothing in the states page would show me what was hitting the normal
queue. Transmission on my seedbox shows it using more than the
22Kb/sec I've allotted for it (approximately half my monthly onpeak
data quota if it downloaded constantly) and I can't figure out where
the filter's failing.
Even more frustrating is that I've limited uploads to 20Kb/sec in
Transmission and none of that seems to hit the low priority queue.
I haven't tried logging packets yet, that's my next step. I'll need
to track down another thumb drive to use, as the one I'm booting off
only has 512mb and a pflog of my bittorrent connections will fill that
up very quickly.
>
>
> Also, you can use HFSC queueing for this as well.
>
> Hierarchical Fair Service Curve (HFSC) of OpenBSD
> https://calomel.org/pf_hfsc.html
I might explore that at a later time, right now I'd like to understand
this first, and then do some testing in HFSC.
>
> --
> Calomel @ https://calomel.org
> Open Source Research and Reference
>
>
> On Tue, Jan 05, 2010 at 07:14:59PM -0500, Aaron Mason wrote:
>>Hi all,
>>
>>I've got the following pf.conf file for limiting bittorrent
>>connections and providing higher priority to a game server. While the
>>latter works wonderfully, the bittorrent connections seem to spill
>>over into the normal queue and it's driving me crazy.
>>
>>My /etc/pf.conf file is as follows:
>>set skip on lo
>>
>># Setting some constants
>>prio_port = "{ 22 53 5900 }"
>>shiori = "192.168.2.241/32"
>>chechemaru = "192.168.2.251/32"
>>wired_if = "rl0"
>>wlan_if= "ath0"
>>
>>hi_bw = "33Mb"
>>norm_bw = "20Mb"
>>lo_bw = "178415b"
>>
>>altq on $wired_if cbq bandwidth 54Mb queue { wired_hi, wired_norm, wired_lo
}
>> queue wired_hi bandwidth $hi_bw priority 2
>> queue wired_norm bandwidth $norm_bw cbq(default) priority 3
>> queue wired_lo bandwidth $lo_bw priority 4
>>
>>altq on $wlan_if cbq bandwidth 54Mb queue { wlan_hi, wlan_norm, wlan_lo }
>> queue wlan_hi bandwidth $hi_bw priority 2
>> queue wlan_norm bandwidth $norm_bw cbq(default) priority 3
>> queue wlan_lo bandwidth $lo_bw priority 4
>>
>># SSH and DNS traffic as well
>>pass out quick on $wired_if proto { tcp udp } to any port $prio_port \
>> queue wired_hi
>>pass out quick on $wired_if proto { tcp udp } from any port $prio_port \
>> queue wired_hi
>>pass out quick on $wlan_if proto { tcp udp } to any port $prio_port \
>> queue wlan_hi
>>pass out quick on $wlan_if proto { tcp udp } from any port $prio_port \
>> queue wlan_hi
>>
>>#High priority to Shiori
>>pass out quick on $wired_if to $shiori queue wired_hi
>>pass out quick on $wlan_if from $shiori queue wlan_hi
>>
>>#Low priority and limiting to Chechemaru
>>#NOTE: BT connections are bidirectional, hence the seemingly \
>>#redundant rules
>>pass out quick on $wired_if to $chechemaru queue wired_lo
>>pass out quick on $wired_if from $chechemaru queue wired_lo
>>pass out quick on $wlan_if to $chechemaru queue wlan_lo
>>pass out quick on $wlan_if from $chechemaru queue wlan_lo
>>
>># Everything else gets normal priority
>># pass out quick on $wired_if queue wired_norm
>>#pass
>>block in on ! lo0 proto tcp to port 6000:6010
>>
>>A typical output from pftop shows the contents of
>>http://paste2.org/p/596043 - notice the upstream going crazy.
>>Unfortunately pfTop hasn't been updated to take advantage of the
>>changes to pf, so it refuses to display the rules. I'd do it myself
>>if I had a better understanding of how pf worked within, but I'm not
>>quite at that stage yet.
>>
>>A very hard cluestick is greatly appreciated, to go along with the
>>concussion I am
Re: PF cluestick please - low priority queue spills over into normal queue
Aaron,
When you say, "seem to spill over into the normal queue" do you mean
the bittor queue is borrowing bandwidth from the total amount of
bandwidth available?
You may need to set a limit on the bittor queue if you want to limit
its bandwidth. The OpenBSD Faq says, CBQ queues are arranged in an
hierarchical manner. At the top of the hierarchy is the root queue
which defines the total amount of bandwidth available. Child queues
are created under the root queue, each of which can be assigned some
portion of the root queue's bandwidth. For example, queues might be
defined as follows:
Root Queue (2Mbps)
Queue A (1Mbps)
Queue B (500Kbps)
Queue C (500Kbps)
Also, you can use HFSC queueing for this as well.
Hierarchical Fair Service Curve (HFSC) of OpenBSD
https://calomel.org/pf_hfsc.html
--
Calomel @ https://calomel.org
Open Source Research and Reference
On Tue, Jan 05, 2010 at 07:14:59PM -0500, Aaron Mason wrote:
>Hi all,
>
>I've got the following pf.conf file for limiting bittorrent
>connections and providing higher priority to a game server. While the
>latter works wonderfully, the bittorrent connections seem to spill
>over into the normal queue and it's driving me crazy.
>
>My /etc/pf.conf file is as follows:
>set skip on lo
>
># Setting some constants
>prio_port = "{ 22 53 5900 }"
>shiori = "192.168.2.241/32"
>chechemaru = "192.168.2.251/32"
>wired_if = "rl0"
>wlan_if= "ath0"
>
>hi_bw = "33Mb"
>norm_bw = "20Mb"
>lo_bw = "178415b"
>
>altq on $wired_if cbq bandwidth 54Mb queue { wired_hi, wired_norm, wired_lo }
> queue wired_hi bandwidth $hi_bw priority 2
> queue wired_norm bandwidth $norm_bw cbq(default) priority 3
> queue wired_lo bandwidth $lo_bw priority 4
>
>altq on $wlan_if cbq bandwidth 54Mb queue { wlan_hi, wlan_norm, wlan_lo }
> queue wlan_hi bandwidth $hi_bw priority 2
> queue wlan_norm bandwidth $norm_bw cbq(default) priority 3
> queue wlan_lo bandwidth $lo_bw priority 4
>
># SSH and DNS traffic as well
>pass out quick on $wired_if proto { tcp udp } to any port $prio_port \
> queue wired_hi
>pass out quick on $wired_if proto { tcp udp } from any port $prio_port \
> queue wired_hi
>pass out quick on $wlan_if proto { tcp udp } to any port $prio_port \
> queue wlan_hi
>pass out quick on $wlan_if proto { tcp udp } from any port $prio_port \
> queue wlan_hi
>
>#High priority to Shiori
>pass out quick on $wired_if to $shiori queue wired_hi
>pass out quick on $wlan_if from $shiori queue wlan_hi
>
>#Low priority and limiting to Chechemaru
>#NOTE: BT connections are bidirectional, hence the seemingly \
>#redundant rules
>pass out quick on $wired_if to $chechemaru queue wired_lo
>pass out quick on $wired_if from $chechemaru queue wired_lo
>pass out quick on $wlan_if to $chechemaru queue wlan_lo
>pass out quick on $wlan_if from $chechemaru queue wlan_lo
>
># Everything else gets normal priority
># pass out quick on $wired_if queue wired_norm
>#pass
>block in on ! lo0 proto tcp to port 6000:6010
>
>A typical output from pftop shows the contents of
>http://paste2.org/p/596043 - notice the upstream going crazy.
>Unfortunately pfTop hasn't been updated to take advantage of the
>changes to pf, so it refuses to display the rules. I'd do it myself
>if I had a better understanding of how pf worked within, but I'm not
>quite at that stage yet.
>
>A very hard cluestick is greatly appreciated, to go along with the
>concussion I am suffering from banging my head on the desk.
>
>Regards
>
>
>--
>Aaron Mason - Programmer, open source addict
>I've taken my software vows - for beta or for worse
Re: PF cluestick please - low priority queue spills over into normal queue
> "Aaron" == Aaron Mason writes: Aaron> hi_bw = "33Mb" Aaron> norm_bw = "20Mb" Aaron> lo_bw = "178415b" Aaron> A typical output from pftop shows the contents of Aaron> http://paste2.org/p/596043 - notice the upstream going crazy. Aaron> Unfortunately pfTop hasn't been updated to take advantage of the Aaron> changes to pf, so it refuses to display the rules. I'd do it myself Aaron> if I had a better understanding of how pf worked within, but I'm not Aaron> quite at that stage yet. I don't see anything that is exceeding the threshold. 33M > 387 20M > 3273 178K > 20K 33M > 359 20M > 48K 178K > 18K Where do you see "going crazy"? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
