[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100831214808.GA32141@ms2.inr.ac.ru>
Date: Wed, 1 Sep 2010 01:48:08 +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!
> Documentation describes latency as something intuitively clear: "the
> maximum amount of time a packet can sit in the TBF"
> but tc implementation handles it something like: "an additional time
> packet can sit int the TBF after main waiting queue which size is
> equal to the burst size is completely full.". It doesn't seem to have
> any sense.
Seems, I still can tell what I really meant there:
burst is supposed to be handled instantly (unless peak rate is not infinite).
So that, latency is really (limit - burst)/rate.
Indeed, the case when limit < burst was missed in tc,
latency should be 0 in this case.
So, think: formula latency = limit/rate, which you suggest, is obviously
wrong (correct me): everything which is out of bucket is drained with rate of tbf,
but everyhing inside the burst is drained with rate of the device, which
cannot even be estimated on base of tbf parameters. (Again, here I ignore
the case when peak rate is set)
So, it looks like tc is almost correct, only it should print 0 instead
of negative value. And the phrase in documentation should sound like:
"maximal queuing delay introduced by TBF".
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
Powered by blists - more mailing lists