All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stef Coene <stef.coene@docum.org>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Low latency on large uploads - almost done but not quite.
Date: Sun, 15 Jun 2003 12:00:10 +0000	[thread overview]
Message-ID: <marc-lartc-105567852429475@msgid-missing> (raw)
In-Reply-To: <marc-lartc-105560610320685@msgid-missing>

On Sunday 15 June 2003 13:44, Thilo Schulz wrote:
> On Sunday 15 June 2003 11:09, you wrote:
> > > Here's still my script, if you are interested to look at it.
> >
> > I'm interested and I have some remarks.
> >
> > Your burst is too low.  I understand you want a minimum burst, but you
> > have to follow some rules.  The best you can do is to remove the
> > burst/cburst option so htb can calculate the minimum burst/cburst for
> > you.
>
> yes, sounds reasonable now that I spend a second thought about it.
>
> > And don't you get quantum errors in your kernel log?  That's because your
> > quantum is too low for the classes.  There is a long explanation for
> > this, see www.docum.org on the faq page.
>
> hmm .. quantum? I have never set quantum with any parameter, or have I?
No.  Quantum is used for leaf classes to determine the amount of packets they 
can send.  It's calculates as rate / r2q.  And r2q is 10 by default.  You can 
overrule r2q if you add the htb qdisc and you can overrule quantum if you add 
a htb class.  Quantum must be > 1500 (the size of 1 packet) and < 60000.  

> > You also use different prio's.  This can be ok in most cases, except if
> > you have a low prio class that's sending more data then the configured
> > rate. If you do so, the latency can go up for that class.  I (still)
> > didn't test it myself, but you can find prove of it on the htb homepage. 
> > The solution for this is to make sure you never put too much traffic in a
> > low prio class.
>
> I have given plenty of bandwidth to the 1:10 class. Quake3 streams are max.
> 1500 bytes/s. And ssh does not use that much either.
Ok.  As long as you are aware of the problem.  You can also try to limit the 
amount of packets the filters with a policer.  So there are never too much 
packets in a class.

> > > # now make all qdiscs simple pfifo
> > > # small queues for minimum latency
> > > tc qdisc add dev $DEV parent 1:10 handle 20: pfifo limit 0
> > > tc qdisc add dev $DEV parent 1:11 handle 30: pfifo limit 0
> >
> > Are you sure limit 0 is possible ????
>
> Yes, at least the status command showed me, that the limit was set to 0.
Ok.

Stef

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

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

  parent reply	other threads:[~2003-06-15 12:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-14 15:54 [LARTC] Low latency on large uploads - almost done but not quite Thilo Schulz
2003-06-15  9:09 ` Stef Coene
2003-06-15 11:44 ` Thilo Schulz
2003-06-15 12:00 ` Stef Coene [this message]
2003-06-16  7:54 ` [LARTC] Low latency on large uploads - almost done but not Corey Rogers
2003-06-17 18:16 ` [LARTC] Low latency on large uploads - almost done but not quite sufcrusher
2003-06-18 12:32 ` Thilo Schulz
2003-06-18 19:10 ` sufcrusher

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-105567852429475@msgid-missing \
    --to=stef.coene@docum.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.