i was going to bitch about not searching archives, but
last time i touched on this topic was on misc@, so i don't
think i can really complain...
'bittorrent queue' is effective search for misc@ archive,
with respect to this.
hopefully i will make sense. i notice you have no rdr on
ext to LAN machine ports:bittorrent ? is that because of
it being handled in PPP/tun0 land?
On Fri, Mar 05, 2004 at 12:41:07AM -0500, Ray wrote:
> My cousins use BitTorrent and I've attempted to
> limit their uploads to ~5kbps but downloads often max out at 200kbps.
> altq on $ext_if cbq bandwidth 100Kb queue {bt_ext std_ext web_ext cs_ext ssh_aim_ext
> dns_ext tcp_ack_ext ntp_ext}
> queue bt_ext bandwidth 6Kb priority 0 cbq #BitTorrent
> queue std_ext bandwidth 20% cbq(default red ecn) #Regular crap
> altq on $int_if cbq bandwidth 100% queue {net_int local_int}
> #Internet traffic
> queue net_int bandwidth 1.3Mb {bt_int std_int web_int cs_int ssh_aim_int dns_int
> ntp_int}
> queue bt_int bandwidth 5% priority 0 cbq #BitTorrent
> queue std_int bandwidth 10% cbq(default) #Regular crap
> # Certain people are not cooperating willingly. We shall try force now.
> pass out on $ext_if proto tcp to port {6879><6890 8879><8890} synproxy state queue
> (bt_ext)
> pass out on $int_if proto tcp from port {6879><6890 8879><8890} synproxy state queue
> (bt_int)
this in specific what i was touching on on the misc@ post.
i found that when i tried catching bittorrent with only a pass out,
i was effectively not queueing my bittorrent traffic into my
bittorrent queues; because i had a stateful pass in that they'd
fall into, or a rdr pass, something like that...
basically, if you only queue bittorrent out, you will end up not
queueing any outbound traffic for what the bittorrent client serves
to people who connect to the local peer after the local peer has
started serving.
some of the traffic is caught, but the other traffic usually ended up
in the default queue; so bittorrent was creating data which was
essentially queued either into the bittorrent queue OR into the
default queue; which created a scenario allowing bittorrent to
be consuming more bandwidth than my model was trying to plan for.
by ensuring i was queueing to bittorrent queues also all *incoming*
traffic which was bound to be redirected back to the bittorrenting
peer on the LAN, i was able to keep all the traffic queued as i
fancy, it works for me quite well and unfailingly.
i posted pf.conf on both the gateway machine and the desktop PC where
i do the bittorrenting back on that misc@ thread. it's bleeding huge
because i make my life more compilcated than it needs to be.
( note: the pf.conf for gateway is just relevant snippet ).
see if creating provisions for queueing such as :
pass in on $e inet proto tcp from any to ($e) port 6880><6890 modulate state queue(
bt_ext )
pass in on $e inet proto tcp from any port 6880><6890 to ($e) modulate state queue(
bt_ext )
if you are not talking about bittorrent consuming your outbound bandwidth,
but rather your inbound, i may have missed the point entirely, but perhaps
it would still fall as valid.
jared
( ps - i see from checking MARC that some of my pf.conf stuff got munged up
with escaping the lines to wrap at 80 column or whatever, so be warned to
not just c/p it )
--
[ openbsd 3.4 GENERIC ( feb 27 ) // i386 ]
