Hi, im doing something like this:
tc qdisc add $DEV parent 1:110 handle 110: estimator 1sec 8sec \
tbf rate 1Mbit burst ??? limit ???
I''ve been triying with diferent values for burst, limit and latency,
but
we cant understand how to determine the correct values for them.
In "Short evaluation of linux token-bucket-filter queueing discipline"
by Kurt Wagner we learned that queue size=limit+bucket size, but we dont
know how to determine limit, burst and latency.
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.
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?.
Thanks.
Alex Leyva
Gobierno del Distrito Federal
Oficialia Mayor
Comite Ejecutivo de Desarrollo Informatico
Direccion de Nuevas Tecnologias
Hi Folks, Is there a way to deal with download accelerator programs, such as Download Accelerator Plus? -- Luiz Felipe Ceglia - Staff TereNet lceglia@terenet.com.br - +55-21-9135-3679
Yes. Patch SFQ to use only IP in hash and no port :) On Sat, 23 Mar 2002, Luiz Felipe Ceglia wrote:> Hi Folks, > > Is there a way to deal with download accelerator programs, such as > Download Accelerator Plus? > > > -- > Luiz Felipe Ceglia - Staff TereNet > lceglia@terenet.com.br - +55-21-9135-3679 > > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > >
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. > > In "Short evaluation of linux token-bucket-filter queueing discipline" > by Kurt Wagner we learned that queue size=limit+bucket size, but we dont > know how to determine limit, burst and latency.I state that the queue size is equal to limit MINUS the bucket size, not PLUS the bucket size. Whereas queue size is no configurable parameter in TBF, I thought it would better describe TBF''s shaping/dropping behavior if I write it like that. Regarding the way to set burst, limit and latency I wan''t to remind that you don''t have to find values for all of them, as latency is approximately (limit - burst) / rate. So TBF give''s you the freedom of choice. You can choose burst and limit, or burst and latency to configure it, as the HOWTO states in chapter 9.2. 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 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... bye, Kurt
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 isempty> (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/