All of lore.kernel.org
 help / color / mirror / Atom feed
From: don-lartc@isis.cs3-inc.com (Don Cohen)
To: lartc@vger.kernel.org
Subject: [LARTC] how to get the latency down on maxed out classes?
Date: Sun, 08 Dec 2002 17:30:16 +0000	[thread overview]
Message-ID: <marc-lartc-103936889825333@msgid-missing> (raw)
In-Reply-To: <marc-lartc-103926701306950@msgid-missing>

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

You understand what's going on here?
As I recall, both pfifo and sfq default to queues of length 128
packets.  If you fill that with 1500 byte packets you have ~200Kbytes
which is about 1.6Mbits.  At 64Kbit/sec that would take ~30 sec to
send so your latency could be as high as 30 sec.
You can limit this latency by reducing the queue size.

On the other hand, the application that fills the queue evidently
doesn't mind large latency.  Otherwise it wouldn't fill the queue.

I think I posted to this list once a description (maybe even the
code?) of another way to limit latency - drop packets that have been
in the queue for more than a timeout period (I tend to use 3 sec).

SFQ should have the desirable result that one tcp connection won't
slow down another one or a ping.

 > 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).
You consider 200ms high?  One max size packet = 1500 bytes = 12Kbit
which is about 200ms on a 64Kbit link.  You can't expect to do better.

 > 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.
RED should be independent of HTB.  
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

  parent reply	other threads:[~2002-12-08 17:30 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
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 [this message]
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-103936889825333@msgid-missing \
    --to=don-lartc@isis.cs3-inc.com \
    --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.