On 2009-05-27, irix <i...@ukr.net> wrote:
> Assume that you are right and the traffic can Shape only outlet
> for what purpose then in other projects (freebsd, linux, netbsd)
> including the original altqd opportunity for shaping incoming traffic
> via CDNR has been included?
so, let's look at FreeBSD's manpage.
ALTQ_CDNR Build the traffic conditioner. This option is meaningless at
the moment as the conditioner is not used by any of the
available disciplines or consumers.
or a fairly recent NetBSD list post:
The input limiter absolutely doesn't work under NetBSD-3, it seems,
and I've found some other posts on the web that seem to confirm this.
[...] I have a NetBSD-4 build of this box, which is an embeded system, which
I could deploy in this application, but it's not a trivial exercise to do
so. So, I'm wondering if anyone has used and can report whether the input
traffic conditioner actually works to limit traffic on input traffic under
NetBSD-4.
...
>> But under dynamic queues, I understand, the creation of a large number of
> dynamic patterns.
>> For example creates template for the queue with an indication of the speed
> such as 512Kbit / s,
>> and then creates template for the filter of which you can
>> specify a subnet like 192.168.1.0/24 and this pattern break this subnet to
> the desired number of rules in this case,
>> to 254, and under each This rule will create a dynamic part of the dynamic
> pattern of 512Kbit / s for each rule.
>
On 2009-05-27, (private) HKS <hks.priv...@gmail.com> wrote:
> What?
If you want to throttle all your clients to, say, 512Kb/sec, you need a
stack of separate queues, and a stack of match rules for them. You can set
them up individually via pfctl/pf.conf but it's a bit messy, you'd probably
want to do part of it via some script or preprocessor. (I think using a
shell script to generate a file to include would be viable though).
Real dynamic queues would be created and destroyed on-the-fly which
could help it scale a bit further, but I don't know how useful it would
be, the first thing that comes to mind is memory use, but each extra
queue doesn't use _all_ that much from the pool unless it's actively
in-use. There might be problems other than memory when using a huge
number of queues, I don't know, never used more than a handful here...
something for someone who has a big setup to look at and profile, really.
