netdev - Re: [RFC][PATCH] QoS TBF and latency configuration misbehavior

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]

Message-ID: <20100831223402.GA7101@ms2.inr.ac.ru>
Date:	Wed, 1 Sep 2010 02:34:02 +0400
From:	Alexey Kuznetsov <kuznet@....inr.ac.ru>
To:	Dan Kruchinin <dkruchinin@....org>
Cc:	Jarek Poplawski <jarkao2@...il.com>, netdev@...r.kernel.org,
	Stephen Hemminger <shemminger@...l.org>
Subject: Re: [RFC][PATCH] QoS TBF and latency configuration misbehavior

Hello!

Hmm. Seems, you are right and I was wrong all these years.
Somehow, I did wrong calculation once and this rustied to the brains.
After some thinking the calulation is obviously wrong: no matter what,
in steady state tbf queue is processed with rate R. What a stupid mistake... :-)

Please, also think how to fix the second part of calculation which deals
with peak rate. IMHO (for now :-)) it does not even contribute to latency
and should be deleted.

To Jarek: about the scripts. I do not think something will be broken
by fixing this error. Eventually, if someone used "latency", he meant
something about real latency. And even if the value was generated
using the same wrong logic as tc did, using correct formula would just
increase limit setting.

Alexey
--
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