Btw, about the original question (havent got the
original email left), there is a WFQ implementation for
ALTQ and FreeBSD, but it seems to not work too well:
http://www.criticalsoftware.com/research/pdf/Paper-PS.p
df
http://corn.eos.nasa.gov/qos/qos_results_summary_july98
.html
---
John Bäckstr
> =?iso-8859-1?Q?John_B=E4ckstrand?= writes:
> > > This is not very convincing. Do you actually
know
> > how WFQ
> > > works? If so, please tell us. The doc you sent
did
> > not describe how
> > > it works but what the effects are, and those are
> > entirely consistent
> > > with what SF
=?iso-8859-1?Q?John_B=E4ckstrand?= writes:
> > This is not very convincing. Do you actually know
> how WFQ
> > works? If so, please tell us. The doc you sent did
> not describe how
> > it works but what the effects are, and those are
> entirely consistent
> > with what SFQ does.
> > Hig
> This is not very convincing. Do you actually know
how WFQ
> works? If so, please tell us. The doc you sent did
not describe how
> it works but what the effects are, and those are
entirely consistent
> with what SFQ does.
> High bandwidth flows are limited, low bandwidth flows
get lower
> late
Paul writes:
> No SFQ is not like WFQ... WRR is the closest thing to cisco's
> fair-queue..
> WRR keeps track of the connections using the ip_conntrack .. that's sort of
> what
> cisco's fair-queue does and it checks the bandwidth streams and gives lower
> priority
> to the higher strea
No SFQ is not like WFQ... WRR is the closest thing to cisco's
fair-queue..
WRR keeps track of the connections using the ip_conntrack .. that's sort of
what
cisco's fair-queue does and it checks the bandwidth streams and gives lower
priority
to the higher streams and larger packets.. it's meant
