All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerome Petazzoni <skaya@enix.org>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] shaping/routing
Date: Thu, 20 Dec 2001 10:43:56 +0000	[thread overview]
Message-ID: <marc-lartc-100884506706048@msgid-missing> (raw)
In-Reply-To: <marc-lartc-100874938007273@msgid-missing>


>> I'll again do some advertisement for my bytelimit patch :-)
>> it is a patch for netfilter (iptables) allowing to limit bandwidth,
>> like the "limit" match but allowing to specify rates in bytes/second
>> instead of packets/second.

> Does it have a peakrate? If not, why not?

sort of... it has a very simple algorithm : each "bytelimit" has a bucket
of "tokens", each "token" allowing 1 byte to pass. the bucket has a maximal
size, and "gains" X tokens per second, where X is the "nominal rate". you
can set separately the bucket maximal size and the rate, so for instance,
if you set 1000 bytes/second "rate", and 10000 "bucket size", you'll be
able to do 2000 bytes/second during 10 seconds, or 10000 bytes/second 
during 1 second, and so on. of course, you can combine two rules, if
you want to allow 1000 bytes per second on average, and 2000 bytes per
second while 10 seconds but no more, just chain a 1000 bps rule with 10000
bucketsize, and a 2000 bps rule with 1600 bucketsize.

the "rule of thumb" for bucketsize calculations should be :
- no less than 1600 (that's roughly one ethernet frame)
- rate/HZ for minimal burstiness (IIRC, HZ is 100 for intel, 1024 for alpha,
  don't know for others)

of course, this patch is not as powerful as the full QoS+tc suite ; but
it allows very simple and straightforward shaping. IMHO, the biggest flaw
is the lack of qdisc, so it would be interesting to setup a 3-band qdisc
respecting TOS marks, and set TOS marks with iptables.

and before people start asking why is the point of this patch : if you
have a nice way to configure your iptables rules (web interface for
customers, or whatever), you are *very happy* to integrate bandwidth
shaping into it, instead of having to design another interface for QoS,
which would have to be coupled with the first one anyway :( .

regards,
Jerome Petazzoni <skaya at enix dot org>
--
'Things either exist or they don't,' said Jeremy. 'I am very clear about that.
I have medicine.'
(The Thief of Time)


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/

      parent reply	other threads:[~2001-12-20 10:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-19  8:06 [LARTC] shaping/routing Daniel Wittenberg
2001-12-19 11:41 ` bert hubert
2001-12-19 18:07 ` Jerome PETAZZONI
2001-12-19 23:49 ` bert hubert
2001-12-20  5:46 ` Daniel Wittenberg
2001-12-20  5:55 ` Jim Fleming
2001-12-20  6:37 ` Daniel Wittenberg
2001-12-20 10:34 ` Jerome Petazzoni
2001-12-20 10:43 ` Jerome Petazzoni [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-lartc-100884506706048@msgid-missing \
    --to=skaya@enix.org \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.