Thank you for your reply,
yes, your right so far. For a single user "inbound" bandwidth management
makes no sense. In terms of network management only "real" outbound
bandwidth management makes sense: If the packets still arrived, why throwing
them away?
After all, in my case we have 4 users paying the line and sharing it. So
sharing should be fair. This could be done with some cbq or hfsc "inbound"
bandwidth management (outbound bandwidth management on the internal
interface). But whatever scheduler I use, the result is still the same as in
my example with priq. So reduced example complexity and started asking for
help.
> On 11/7/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > ### QUEUEING ###
> > #
> > #Bandwidth management
> > #
> > ##Define upstream parent queue (24Kb * 0,95 Overhead) altq on $ext_if
> > priq bandwidth 22Kb queue { up_default up_web up_quick } ##Define
> > downstream parent queue (256Kb * 0,95 Overhead) altq on $int_if priq
> > bandwidth 243Kb queue { dn_default dn_quick }
> >
> > ##Define upstream child queues
> > queue up_default priq(default)
> > queue up_quick priority 7 priq
> >
> > ##Define downstream child queues
> > queue dn_default priq(default)
> > queue dn_quick priority 7 priq
>
> apart from what chris said, I don\'t see the point in inbound queuing on a
ADSL line, after all, don\'t you queue just _after_ the bottleneck (the DSL
link)? so if you want to shape your inbound traffic, shouldn\'t it be on the
other side (which you don\'t control)?
>
>
> --knitti
--
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen f|r GMX Partner: http://www.gmx.net/de/go/partner
