lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 7 May 2009 22:49:27 +0300
From:	Denys Fedoryschenko <denys@...p.net.lb>
To:	Jarek Poplawski <jarkao2@...il.com>
Cc:	Patrick McHardy <kaber@...sh.net>,
	Stephen Hemminger <shemminger@...ux-foundation.org>,
	netdev@...r.kernel.org
Subject: Re: [RFC] iproute2/tc caching proposal

On Thursday 07 May 2009 22:27:02 Jarek Poplawski wrote:
> Jarek Poplawski wrote, On 05/07/2009 08:44 PM:
> > Do you mean 30 sec. is to short for a change? I don't know these things
> > enough; your idea looks very nice, but I wonder if you tested how it
> > behaves if e.g. after 15k rules some dev goes away which is used in the
> > next 15k?
>
> Hmm... actually, it seems there should be no problem, except less info on
> the
>
> reason of the failure.
Info will be same, completely. Just case with changing interfaces have to be 
handled correctly in any case, in case of batch. It is difficult to explain, 
each person doing his own way shapers. I can explain even, why in my case 
caching is better. And probably all other, properly done shapers for such 
cases.

But for me critical, that when i load shaper, machine is for 10 minutes eating 
dust (cpu utilisation is high, fans turning like hell :-))) ), and some of 
users have bandwidth without restrictions. 30 secs much better, and still 
here is space for improvement.


>
>
> Jarek P.


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ