I've seen the problem your experiencing before with a 3.8 openbsd pf box
I used to run, as well as a linksys wireless 802.11b router. Bit
torrent no matter what bandwidth you use, hoses the boxes.
On a second incident, I used to work as the network manager for a local
Wireless ISP. I know that bit torrent, and other p2p programs use a lot
of connections, due to pulling the data down from different sources.
This would overload our wireless radios. Not the amount of data being
transmitted, but just because the number of connections sometimes would
be within the thousands. We basically had to ban all p2p traffic on our
network to be able to continue to provide isp services. One customer
could effectively dos 50 or so connected to the same radio on that
tower, also the backhauls (if shared with another tower) would loose
connectivity.
Anyways that's my two cents.
-Jonathan Lindsey
frantisek holop wrote:
hmm, on Wed, Jan 31, 2007 at 05:32:32PM +0100, Han Boetes said that
The official bittorrent client is rather resource-hungry. Consider
using rtorrent which is written in c++.
i certainly will.
BitTorrent is no doubt a bit slower and bigger in memory,
but i can't see why it makes pf throw up. is it because
of the way python apps access the network?
the machine itself is responsive, load is load, etc.
only the network starts to crawl, and the pipe is far from full.
maybe my pf rules are bad, i'll try to reproduce this on
my 4.0 notebook.
-f
