* [LARTC] how to guarantee 1/numflows bandwidth to each flow
@ 2005-05-09 18:17 Scott Mcdermott
2005-05-10 18:42 ` Krystian Antoni
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Scott Mcdermott @ 2005-05-09 18:17 UTC (permalink / raw)
To: lartc
I am looking for a simple way to guarantee to each flow
going through my traffic control point 1/numflows of
bandwidth. I thought using SFQ would do this effectively
but it appears to be quite unfair: a very high speed
download that fills the pipe easily starves smaller flows to
the point where it becomes unusable (especially if they are
at all interactive)
Because numflows is dynamic, I'm not sure how I would have
the bandwidth allocated to each flow change dynamically and
automatically as flows are added and removed.
Anyone have an idea how to implement this? Thanks.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [LARTC] how to guarantee 1/numflows bandwidth to each flow
2005-05-09 18:17 [LARTC] how to guarantee 1/numflows bandwidth to each flow Scott Mcdermott
@ 2005-05-10 18:42 ` Krystian Antoni
2005-05-11 3:35 ` [LARTC] how to guarantee 1/numflows bandwidth to each gypsy
2005-05-11 22:53 ` Andy Furniss
2 siblings, 0 replies; 4+ messages in thread
From: Krystian Antoni @ 2005-05-10 18:42 UTC (permalink / raw)
To: lartc
[-- Attachment #1.1: Type: text/plain, Size: 1201 bytes --]
if u find sfq unfair u can try WRR.
but if for example one flow is eating all the badwidth and a new flow
starts, the new has to "claim" he's part by going from slow transfer to fast
one.
u can try making normal QOS based on classes and give one class to every
customer. should work best. remember to do the same on both upload and
download
On 5/9/05, Scott Mcdermott <lartc@vaxerdec.net> wrote:
>
> I am looking for a simple way to guarantee to each flow
> going through my traffic control point 1/numflows of
> bandwidth. I thought using SFQ would do this effectively
> but it appears to be quite unfair: a very high speed
> download that fills the pipe easily starves smaller flows to
> the point where it becomes unusable (especially if they are
> at all interactive)
>
> Because numflows is dynamic, I'm not sure how I would have
> the bandwidth allocated to each flow change dynamically and
> automatically as flows are added and removed.
>
> Anyone have an idea how to implement this? Thanks.
>
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>
--
Miłego Dnia
Krystian Antoni
[-- Attachment #1.2: Type: text/html, Size: 1636 bytes --]
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [LARTC] how to guarantee 1/numflows bandwidth to each
2005-05-09 18:17 [LARTC] how to guarantee 1/numflows bandwidth to each flow Scott Mcdermott
2005-05-10 18:42 ` Krystian Antoni
@ 2005-05-11 3:35 ` gypsy
2005-05-11 22:53 ` Andy Furniss
2 siblings, 0 replies; 4+ messages in thread
From: gypsy @ 2005-05-11 3:35 UTC (permalink / raw)
To: lartc
Scott Mcdermott wrote:
>
> I am looking for a simple way to guarantee to each flow
> going through my traffic control point 1/numflows of
> bandwidth. I thought using SFQ would do this effectively
> but it appears to be quite unfair: a very high speed
> download that fills the pipe easily starves smaller flows to
> the point where it becomes unusable (especially if they are
> at all interactive)
>
> Because numflows is dynamic, I'm not sure how I would have
> the bandwidth allocated to each flow change dynamically and
> automatically as flows are added and removed.
>
> Anyone have an idea how to implement this? Thanks.
Perhaps you should look at esfq rather than sfq. esfq lets you specify
quantum in bytes, depth in flows, limit in packets, and a source or dest
hash. Don't apply any sfq to what Wondershaper calls "interactive".
You need to match esfq to the kernel version; 2.6 uses a different esfq
than 2.4.
--
buck
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [LARTC] how to guarantee 1/numflows bandwidth to each
2005-05-09 18:17 [LARTC] how to guarantee 1/numflows bandwidth to each flow Scott Mcdermott
2005-05-10 18:42 ` Krystian Antoni
2005-05-11 3:35 ` [LARTC] how to guarantee 1/numflows bandwidth to each gypsy
@ 2005-05-11 22:53 ` Andy Furniss
2 siblings, 0 replies; 4+ messages in thread
From: Andy Furniss @ 2005-05-11 22:53 UTC (permalink / raw)
To: lartc
Scott Mcdermott wrote:
> I am looking for a simple way to guarantee to each flow
> going through my traffic control point 1/numflows of
> bandwidth. I thought using SFQ would do this effectively
> but it appears to be quite unfair: a very high speed
> download that fills the pipe easily starves smaller flows to
> the point where it becomes unusable (especially if they are
> at all interactive)
If you are shaping from the "wrong" end of the bottleneck then you need
to back off from link speed to get control - and it still won't be perfect.
It's best to priorotise interactive traffic and not mix it with bulk
traffic.
Andy.
>
> Because numflows is dynamic, I'm not sure how I would have
> the bandwidth allocated to each flow change dynamically and
> automatically as flows are added and removed.
>
> Anyone have an idea how to implement this? Thanks.
>
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-05-11 22:53 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-05-09 18:17 [LARTC] how to guarantee 1/numflows bandwidth to each flow Scott Mcdermott
2005-05-10 18:42 ` Krystian Antoni
2005-05-11 3:35 ` [LARTC] how to guarantee 1/numflows bandwidth to each gypsy
2005-05-11 22:53 ` Andy Furniss
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.