Re: Fair distribution of borrowed bandwidth with a lot of users

2007-04-17 Thread Federico Giannici

Lawrence Horvath wrote:

have you considered percentages?


Using percentages is equivalent to using the corresponding values.
It doesn't solve my problem.



or using a script to inject ips into
a tables based queue setup?


I already use a script to generate the pf.conf file, but I cannot 
understand what do you mean with tables based queue.


How can it change the way the bandwidth in excess is distributed between 
queues?


Bye.



On 16/04/07, Federico Giannici [EMAIL PROTECTED] wrote:

As there was no reply to this email of mine, anybody can tell me if
there is some other place where I can submit this question?

At least, anybody can tell me if my theory about bandwidth assignments
is wrong?

Thanks.


Federico Giannici wrote:
 I have a problem creating a policy to make a fair use of available
 bandwidth in a situation with a lot of potential users.

 We have a certain number of users, each one with a committed bandwidth
 of X or Y. We setup a queue system with an HFSC queue for each user,
 with a bandwidth (linkshare parameter) proportional to X or Y.

 This system doesn't seem to work in a fair way: when an user does a 
HUGE

 download with a very large number of packets and bytes per second, it
 steals almost all bandwidth to the other users requiring only a little
 of bandwidth.

 It seems that the borrowed bandwidth is distributed to the queues based
 on the amount of required packets (or bytes). Indeed I'd like that the
 bandwidth is distributed strictly proportional to the assigned 
bandwidth.


 Let's make and example:
 Both users A and B have an assigned bandwidth of 1 bps.
 User A currently requires 4 bps.
 User B currently requires 100 bps.
 There are currently available 10 bps.

 I'd like that the 10 bps would be equally distributed to both users (as
 they have the same assigned bandwidth), so both had 5 bps. User A 
uses 4

 bps and leaves 1 bps to user B that so uses 6 bps.

 Indeed it seems that, as user B requires 25 times more bandwidth of 
user

 A, then it is assigned almost ALL bandwidth, and user A is not able to
 use more then it's committed 1 bps, and so 3 out of 4 bits are dropped!

 Is this true?
 Is there a way to obtain my desired behavior?

 Please note that I cannot simply increase the commited bandwidth of 
both

 users to 5 bps because there are a lot of other potential users (that
 currently are not using bandwidth) so the sum of bandwidths would
 exceeds the bandwidth of the parent queue.


 Thanks.




--
___
__
   |-  [EMAIL PROTECTED]
   |ederico Giannici  http://www.neomedia.it
___


Re: Fair distribution of borrowed bandwidth with a lot of users

2007-04-17 Thread Peter N. M. Hansteen
Federico Giannici [EMAIL PROTECTED] writes:

 or using a script to inject ips into
 a tables based queue setup?

 I already use a script to generate the pf.conf file, but I cannot
 understand what do you mean with tables based queue.

I think what he means is, you use pass from tablename queue foo constructs

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/
First, we kill all the spammers The Usenet Bard, Twice-forwarded tales
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.


Re: Fair distribution of borrowed bandwidth with a lot of users

2007-04-17 Thread Bob DeBolt
Hi Federico Giannici

Posting you pf.conf will be of considerable benefit
when attempting to seek help for something that has the complexity you
are currently dealing with.

Additionally, the type connection you have, i.e. DSL, cable etc. as the
variations each of these has throughout the day will skew the appearance
of your results etc.

Supplying your complete pf.conf correctly commented with what you are
wanting each rule and queue to accomplish is a good place to start.

You will consistently find that without adequate information it will be
difficult for people to help you.

Bob





signature.asc
Description: OpenPGP digital signature