On Wed, Sep 01, 2010 at 01:00:53AM +0400, Dan Kruchinin wrote:

On Tue, Aug 31, 2010 at 11:57 PM, Jarek Poplawski [off-list ref] wrote:

quoted

Dan Kruchinin wrote, On 08/31/2010 07:01 PM:

quoted

I'm sorry it seems my email client has broken patch formating.
Here is properly formated one:

diff --git a/tc/q_tbf.c b/tc/q_tbf.c
index dc556fe..850e6db 100644
--- a/tc/q_tbf.c
+++ b/tc/q_tbf.c

@@ -178,7 +178,7 @@ static int tbf_parse_opt(struct qdisc_util *qu, int argc, char **argv, struct nl

      }

      if (opt.limit == 0) {
-             double lim = opt.rate.rate*(double)latency/TIME_UNITS_PER_SEC + buffer;
+             double lim = opt.rate.rate*(double)latency/TIME_UNITS_PER_SEC;

The way limit is calculated here from latency suggests some safety defaults
are taken wrt. the implementation, which could be omitted while setting the
limit directly. You try to change/fix this to adhere to the documentation,
but such a change would definitely break many user configs, so I doubt it's
the right solution here. Probably you should rather think about fixing the
manual.

Thank you for comments.
The only thing that embarrasses me abut documentation fixing is that
the latency loses all its sense.

Hmm... As a matter of fact, I'm not too picky about docs (and happy if
they don't skip some params at all), but your test with such a high
burst wrt. the rate didn't make much sense to me either. ;-)

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.
Moreover, user can pass "limit" value to tc directly and if this limit
value is less than burst size then latency will be improperly
calculated(it'll have a negative value) which is not good as well.

Yes, many params could be misused/abused in tc without a warning, so
people have to test their configs first, and often learn this way how
it really works. So the docs are often secondary, which is not right
of course.

By the way, the following descriptions of TBF algorithm are proposed
the same the manual says:
http://www.opalsoft.net/qos/DS-24.htm
ww.docum.org/docum.org/docs/other/tbf02_kw.ps

If the documentation should be fixed I'm not sure that latency can be
somehow logically described to have any sense at all.

I guess there could be added a warning there is such a difference.

Jarek P.