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] how to get the latency down on maxed out classes?
Date: Sat, 07 Dec 2002 15:15:48 +0000	[thread overview]
Message-ID: <marc-lartc-103927420410367@msgid-missing> (raw)
In-Reply-To: <marc-lartc-103926701306950@msgid-missing>

On Saturday 07 December 2002 14:15, Abraham van der Merwe wrote:
> Hi!
>
> I'm using HTB to shape traffic to/from clients, but one of the problems I
> have is that once a class utilizes its maximum potential, they latency
> spirals out of control.
>
> For example:
>
>      .-----.
>
>      | isp |
>
>      `-----'
>
>    .--------.
>
>    | shaper |
>
>    `--------'
>
>    .--------.
>
>    | client |
>
>    `--------'
>
> lets say I want to limit traffic to/from client to 64kbit. now, client
> opens a tcp connection blasting away at full speed.
>
> If client now pings isp, it gets on average around 7 seconds latency. I
> tried to improve this by using SFQ on the leaf nodes of my HTB hierarchy,
> but that does not really improve the situation, only makes it much worse.
> with SFQ I get anything between 250ms and 13 seconds latency.
>
> I then tried fifos. With small packet fifos the packet loss is just
> to great to be of any use and even then the latency is quite high (~200ms).
> If I make the fifos big enough so that unreasonable numbers of packets
> isn't dropped, it just doesn't do much to the latency/or throughput. This
> behaviour kind of makes sense, but doesn't help me :P
>
> I'm thinking of using RED, but the number of parameters is daunting and I
> have no idea how the HTB rate correlates to packet size and burst rates for
> red.
>
> Does anybody have any idea how to get the latency down and still maintain
> the correct throughput?
If you want low latency for some traffic (ping, telnet, ssh), then you can 
create a separate class for it. 
And if you have a 64kbit modem, you have to be sure you never send more data 
then the modem can handle.  If you send more data, the hugh modem queue's 
will be filled so they create a lot of latency.  So for a 64kbit link, try to 
limit ALL traffic to 60kbit so the queue's of the modem are never filled.

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:[~2002-12-07 15:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-07 13:15 [LARTC] how to get the latency down on maxed out classes? Abraham van der Merwe
2002-12-07 13:43 ` hare ram
2002-12-07 15:15 ` Stef Coene [this message]
2002-12-07 16:49 ` Abraham van der Merwe
2002-12-08 12:09 ` Stef Coene
2002-12-08 16:27 ` David Boreham
2002-12-08 17:30 ` Don Cohen
2002-12-09 16:11 ` Abraham van der Merwe
2002-12-09 16:44 ` Don Cohen
2002-12-09 18:39 ` David Boreham

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-103927420410367@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.