As stupid as it can sound, you could develop a protocol to make routers
talk each other and say how much bandwith is available in between. I
think there's no other really sane way of inbound traffic control.
Dropper techniques are a cheap trick nice for little networks. Serious
and big perform
Hello ,
In addition CDNR still has the "3 color marker", which, if slightly
reworked,you can get a different dynamic shaper. For each color
would be to set a speed,
and switch between the colors would be implemented through traffic past in the
ends of time.
For example <10M
Hello ,
Today I felt CDNR in NetBSD-5
Works fine. No claims.
Why write that does not work, I can not even guess. "I use in NetBSD-2, and
NetBSD-5.
It works without reproach.
interface pvc1
conditioner pvc1 ef_cdnr >
filter pvc1 ef_cdnr 0 0 172.16.4.176 0 0
> so, let's look at FreeBSD'
> we already do some mitigation for that in certain drivers.
> $ cd /sys/dev; grep MCLGETI pci/* ic/*
...
Oh, that's great to hear! I missed.
29 MAQ 2009 G. 13:28 POLXZOWATELX irix NAPISAL:
> And then you're going to add a dropper ?
You had to try "man MCLGETI" before asking here. At least.
--
an
Hello ,
And then you're going to add a dropper ?
> we already do some mitigation for that in certain drivers.
>
> $ cd /sys/dev; grep MCLGETI pci/* ic/*
> pci/if_bge.c: MCLGETI(m, M_DONTWAIT, &sc->arpcom.ac_if, MCLBYTES);
> pci/if_bge.c: MCLGETI(m, M_DONTWAIT, &sc->arpcom.ac_if, BGE_JLEN);
>
On 2009-05-28, Anton Maksimenkov wrote:
> 2009/5/28 SJP Lists :
>> In other words, doing it on the incoming is pointless. Thus, as in
>> your examples, the logic behind shaping only on the outbound.
>>
>> i.e.You can easily delay sending something you have, but you have
>> little to no control ov
> I know this is an option, but forcing the resending of traffic doesn't
> seem to be the most efficient method to me, when I could instead just
> shape that same traffic when it leaves another interface.
That's what I do, and that's how I know it can provide the benefit I claim,
though that makes
Hello ,
>
>>> 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 lik
2009/5/28 SJP Lists :
> In other words, doing it on the incoming is pointless. Thus, as in
> your examples, the logic behind shaping only on the outbound.
>
> i.e.You can easily delay sending something you have, but you have
> little to no control over the ingress traffic of a link where only the
On Wed, May 27, 2009 at 10:44 PM, SJP Lists wrote:
> I know this is an option, but forcing the resending of traffic doesn't
> seem to be the most efficient method to me, when I could instead just
> shape that same traffic when it leaves another interface.
It's a horrible option, but it's what wa
2009/5/28 Johan Beisser :
>> I was trying to highlight to irix that once traffic is received, it is
>> too late to alter the bandwidth it already used coming in.
>>
>> In other words, doing it on the incoming is pointless. Thus, as in
>> your examples, the logic behind shaping only on the outboun
> I was trying to highlight to irix that once traffic is received, it is
> too late to alter the bandwidth it already used coming in.
Dropping packets you've already received can have the impact of causing
well-behaved hosts to back off when sending future packets. That's a useful
result in itself
On 2009-05-27, irix 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 manpag
2009/5/27 irix :
> Hello Misc,
>
>> since queueing only happens at output, that's going to be totally
>> useless. it's not just a question of how altq distinguishes traffic,
>> you're asking to totally change how altq works.
>
> Okey, i see. But I can not understand why you are sure that traffic
On Wed, May 27, 2009 at 12:02 PM, SJP Lists wrote:
> Thanks Lars and Johan,
>
> I was trying to highlight to irix that once traffic is received, it is
> too late to alter the bandwidth it already used coming in.
>
> In other words, doing it on the incoming is pointless. Thus, as in
> your exampl
2009/5/28 Johan Beisser :
> On Wed, May 27, 2009 at 11:04 AM, SJP Lists wrote:
>> How do you shape traffic that you have already received? Or to put it
>> another way, how do you alter the past?
>
> I've always just assigned inbound traffic to the existing outbound
> queues. My assumption is that
Hello ,
> * irix [2009-05-27 18:12]:
>> But I can not understand why you are sure that traffic can only
>> outlet Shape
>
> i can not understand why you want to shape outlets.
>
> you don't understand that inbound shaping doesn't work because you
> have obviously no idea how the network stack wo
On Wed, May 27, 2009 at 11:04 AM, SJP Lists wrote:
> How do you shape traffic that you have already received? Or to put it
> another way, how do you alter the past?
I've always just assigned inbound traffic to the existing outbound
queues. My assumption is that the responding traffic would use t
SJP Lists wrote:
> 2009/5/28 irix :
>
>> Okey, i see. But I can not understand why you are sure that traffic
>> can only outlet Shape , You can say that's silly to try to Shape traffic
> that came,
>> but if it works it's worse than outgoing (if only for tcp) it is not
>> stupid ?
>
> How do
2009/5/28 irix :
> Okey, i see. But I can not understand why you are sure that traffic
> can only outlet Shape , You can say that's silly to try to Shape traffic
that came,
> but if it works it's worse than outgoing (if only for tcp) it is not
> stupid ?
How do you shape traffic that you hav
* irix [2009-05-27 18:12]:
> But I can not understand why you are sure that traffic can only
> outlet Shape
i can not understand why you want to shape outlets.
you don't understand that inbound shaping doesn't work because you
have obviously no idea how the network stack works. there is no
suita
Hello Misc,
> since queueing only happens at output, that's going to be totally
> useless. it's not just a question of how altq distinguishes traffic,
> you're asking to totally change how altq works.
Okey, i see. But I can not understand why you are sure that traffic
can only outlet Shape , Y
On 2009-05-27, irix wrote:
> Hello Misc,
>
> Or may be remove from altq distinguish incoming traffic or outgoing.
> What could box up to the queue as incoming and outgoing.
since queueing only happens at output, that's going to be totally
useless. it's not just a question of how altq distingu
2009/5/27, Henning Brauer :
> may be someone better to do my laundry
you mean you don't have a laundromat yet?
* irix [2009-05-27 06:14]:
> May be someone better to write in a kind of pseudo device ifb
may be someone better to do my laundry
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers,
Hello Misc,
Or may be remove from altq distinguish incoming traffic or outgoing.
What could box up to the queue as incoming and outgoing.
--
Best regards,
irix mailto:i...@ukr.net
Hello Misc,
May be someone better to write in a kind of pseudo device ifb (The
Intermediate Functional Block device) like in linux,
so you can cheat altq. Redirect incoming traffic from the physical device
(fxp0) to a device (ifb0)
and that it passed altq traffic considered as originating
Hello Misc,
Where i can find openbsd public roadmap ?
* irix [2009-05-25 23:04]:
> I want to ask, will be shortly removed cbq?
>
> And when which will be supplemented pf.conf (5) of hfsc more detail
> and with examples ??
>the date and time of all future changes is in our public roadmap,
* irix [2009-05-25 23:04]:
> I want to ask, will be shortly removed cbq?
>
> And when which will be supplemented pf.conf (5) of hfsc more detail
> and with examples ??
the date and time of all future changes is in our public roadmap, with
precision to the second. each roadmap entry also has t
On Mon, May 25, 2009 at 10:35 PM, Philip Guenther wrote:
> 2009/5/25 irix :
>> And it will be added to the main tree?
>
> Let's see, no code, no mention of license, and no demonstration that
> it actually solves a/your problem. How can your question possibly be
> answered?
>
>
> Philip Guenther
>
Hello Misc,
Good, I understand your position, ok.
I want to ask, will be shortly removed cbq?
And when which will be supplemented pf.conf (5) of hfsc more detail
and with examples ??
2009/5/25 irix :
> And it will be added to the main tree?
>Let's see, no code, no mention of license, and
2009/5/25 irix :
> And it will be added to the main tree?
Let's see, no code, no mention of license, and no demonstration that
it actually solves a/your problem. How can your question possibly be
answered?
Philip Guenther
Hello Misc,
And it will be added to the main tree?
* irix [2009-05-25 03:53]:
> About add some queue disciplines, I agree with you.
> But about completion of porting CNDR , about dynamic queues and about
> packet rate limit per state your position is not clear.
>
> Why CNDR porting froze in
* irix [2009-05-25 03:53]:
> About add some queue disciplines, I agree with you.
> But about completion of porting CNDR , about dynamic queues and about
> packet rate limit per state your position is not clear.
>
> Why CNDR porting froze in halfway, Why not bring to the end ?
you are free to d
Hello Misc,
About add some queue disciplines, I agree with you.
But about completion of porting CNDR , about dynamic queues and about
packet rate limit per state your position is not clear.
Why CNDR porting froze in halfway, Why not bring to the end ?
--
Best regards,
irix
* irix [2009-05-24 08:20]:
> Over the past six years, the project altq was not added any new
> features.
no. I don't really see a need to add anything. If anyone does (s)he's
free to submit diffs.
> Although the project is fully prepared to little.
parser error
> There is a shortage of
Hello Misc,
I was wondering when i can't find packet rate limiting per state in pf.
Number of state's per src ip, found. State rate limiting found.
And packet rate limiting per one state (or packet rate limiting at
all) don't found.
This function will be added ?
The altq project
37 matches
Mail list logo
