[ previous ] [ next ] [ threads ]
 From:  =?iso-8859-1?q?Jose=20Iadicicco?= <joseiadicicco at yahoo dot com>
 To:  Adam Nellemann <adam at nellemann dot nu>
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] bandwidth limiting
 Date:  Tue, 11 May 2004 13:43:30 -0300 (ART)
Adam and you all friends:
                          The incoming traffic shaping works perfect!!! I did it works since the
version 21 beta of Monowall ant it solves my problem (i have a net with 12 users that share an
ADSL connecion 512 kbits downdstream and 128 kbits upstream and when one user opens a program like
Kazaa it takes all the bandwidth and the others users cant navegate).
I solve this making pipes of 64 kbits downstream and 32 kbits upstream, it is a solution, but
doesn´t is the BEST solution. I think the best solution would be some way of dinamic sharing of
the bandwidth.
I read a lot of info but i dont know how can I do it!

Can anyone help me and helps a lot of guys like me that has the same problem?


 --- Adam Nellemann <adam at nellemann dot nu> escribió: > Hi,
> Dinesh Nair wrote:
> > On Mon, 10 May 2004, Tony Pitman wrote:
> > 
> > 
> >>Well, it is the incoming traffic that is going to be the big problem. I
> >>need to be able to limit how much bandwidth someone can use for
> >>downloading and web browsing. Please expand (without rehashing too much
> >>as you indicated) on what you mean.
> > 
> > 
> > incoming traffic reaches your m0n0wall before it can be shaped. if it's
> > reached your m0n0wall, it's already put a load on your incoming T1, thus
> > serving no useful purpose in reality.
> While this is true, some time ago there were some posts to the 
> contrary (by someone apparantly with a great deal of knowledge about 
> these things). It would appear that inbound shaping can have some 
> effect, due to packets being dropped, which will apparantly cause most 
> servers to slow down transmission of new packets or something along 
> those lines?
> > however, since you have dual interfaces, you can set outbound traffic
> > shaping on your wan link and outbound shaping on your lan link. the
> > outbound on your lan should be equivalent to the inbound on your wan, and
> > under your control.
> While I'm not sure, I should think it would have (nearly) the same 
> effect if the inbound shaping is done on the WAN interface, at least 
> if a queue is used, as m0n0wall should then accept the packages and 
> hold them in it's own queue, rather than simply dropping them. But as 
> mentioned, it would appear that sometimes it is preferable that 
> packets are dropped, so..?
> = = =
> I guess the issue here is to provide a static "cap" on the inbound 
> bandwidth of 128K, so a given user only gets what has been paid for. 
> The issue of optimal WAN line usage shouldn't be that important (after 
> all it is a T1 line!) and as mentioned there is a good chance that it 
> will actually result in rather good line usage even so.
> I would certainly try shaping both directions (possibly experimenting 
> a bit to see if inbound should be done on the WAN or the LAN IF), only 
> if this seem to cause some kind of problem would I consider removing 
> the inbound shaping (in which case I'd try to do some clever outbound 
> ACK shaping and such instead).
> Regards,
> Adam.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch

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