[ previous ] [ next ] [ threads ]
 From:  =?iso-8859-1?q?Jose=20Iadicicco?= <joseiadicicco at yahoo dot com>
 To:  term at cynisk dot net
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Dynamical Bandwidth Management.
 Date:  Tue, 25 May 2004 12:56:48 -0300 (ART)
Hello Thomas, my name is Jose Iadicicco and I read about your post at the monowall list and saw
you had the same problem that me (I have a network with 12 computers without control of traffic at
each one, and when one PC opens a program like Kazaa or Emule it takes all the available
bandwidt). Now I solved the problem limiting each PC to 8 Kbytes dowload and 4 Kbytes upload (my
internet connection is: 64 Kbytes Downstream and 16 Kbytes Upstream (ADSL)).
I would like to know if you find out how can we made something like this :
I mean, to share the bandwidth dynamically between all PCs no matter what programs opens each one,
all of them may browse the net and use Instant Messaging programs, etc etc.

Thank you in advance!!


>Hello list,
>I've been playing around with the traffic shaper and noticed that it is a
<really useful feature. As it is now I'm using rules that give high weight to
<outgoing SYN packets and all kinds of DNS queries, as well as outgoing ACK
<packets (I have ADSL). These rules combined give very smooth web browsing
<even if a user on the LAN is doing some heavy downloading.
>The problems arise when a user is running an application that uses a high
>number om simultaneous TCP connections (i.e. BitTorrent). Since the NAT
>rules distribute bandwidth on a per-connection (as opposed to per-computer)
>basis, this gives the unwanted effect that this user will occupy almost all
>outgoing bandwidth available with the enormous amount of prioritized
>ACK-packets BitTorrent generates.
>A solution to this would be to have multiple pipes/queues into which the
>packets are re-injected, after passing the initial prioritizing (based on
>individual packet content), and using source-based pipes in the "second
>round" to distribute available bandwidth evenly amongst the clients. This
>seems to be possible, but does this method have any unexpected side effects?
>Will it be possible to re-inject the packets into new queues even three or
>four times without creating heavy delays or similar? I haven't been able to
>set up a realistic test, and I really don't have any idea how much CPU time
>in the m0n0wall the shaper needs.
>Thanks in advance,
>Thomas Hertz

El objetivo escencial del correr es probar los limites de la voluntad humana...

Los mejores usados y las más tentadoras 
ofertas de 0km están en Yahoo! Autos.
Comprá o vendé tu auto en