From: Alex Leyva <aleyva@pichon.df.gob.mx>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Determining tbf parameters
Date: Mon, 01 Apr 2002 16:04:32 +0000 [thread overview]
Message-ID: <marc-lartc-101767715211427@msgid-missing> (raw)
In-Reply-To: <marc-lartc-101682297718443@msgid-missing>
On Thu, 28 Mar 2002, Kurt Wagner wrote:
> Howdi Alex,
>
> On Fri, 22 Mar 2002, Alex Leyva wrote:
>
> > I've been triying with diferent values for burst, limit and latency,
but
> > we cant understand how to determine the correct values for them.
> >
> Now, how to set it depends on what you want to do. Which bursts do you
> wan't to allow, and do you wan't to queue packets when the bucket is
empty
> (introducing additional delay...) or simply drop them?
>
> > We found different formulas to determine the size of the bucket, the
> > latency and the limit, but they doesnt work for us, because we get
> > incoherent values.
>
> If you have some rules of thumb for some sort of setup please post it,
> could be interesting for other people too. However, the general rule is
> that there is no general rule. ;-)
We can't found any formula to determine the setup, but we founded some
"rules", (something like conclusions):
-limit is the size of something like a "prebuffer" for packets waiting for
tockens to be available.
-latency is the amount of time that a packet can sit waiting for tockens
to be available.
-For both values (limit and latency) if the limit (of size or time) is
overpassed the packets are dropped.
-There are NO formulas to determine the setup, there are only formulas to
determine the critical or maximal values for the parameters.
-If we are managing interactive traffic we must mantain the overlimit
packets count down, and we must configure tbf with burst and LATENCY to
do it.
-If we are managing bulk traffic the overlimit count is non important,
but we must know if the dropped packets are important, just like the TOS
maximum reliability, and whe must use burst and LIMIT to do it.
At now we have not probed with interactive traffic or nothing else, just
with ttcp, with to pentium II over a ethernet, directly connected, and
the results was really good.
>
> > We have another question, what is the normal values for dropped and
> > overlimit?.
> > We have:
> > qdisc tbf 110: dev eth1 rate 1Mbit burst 20Kb/8 mpu 0b [0001f400]
limit
> > 40Kb lat 190.7ms
> > Sent 17542230 bytes 11591 pkts (dropped 36, overlimits 35216)
> >
> > is this normal?.
>
> Hmm, 17MByte transmitted with 11591 packets, so your packets are
> approximately 1500 bytes long in average, which makes me guess it
> was a file transfer with TCP and 1.5KB MTU? The values are ok if
> that's the case...
>
We are using ttcp to make the test, with the default values.
We think that if we get better results and we get conclusions more solid
we could contribute it to the howto =-).
>
> bye,
> Kurt
>
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
prev parent reply other threads:[~2002-04-01 16:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-22 18:49 [LARTC] Determining tbf parameters Alex Leyva
2002-03-28 17:09 ` Kurt Wagner
2002-04-01 16:04 ` Alex Leyva [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-101767715211427@msgid-missing \
--to=aleyva@pichon.df.gob.mx \
--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.