From: don-lartc@isis.cs3-inc.com (Don Cohen)
To: lartc@vger.kernel.org
Subject: Re: [LARTC] how to get the latency down on maxed out classes?
Date: Mon, 09 Dec 2002 16:44:00 +0000 [thread overview]
Message-ID: <marc-lartc-103945253522230@msgid-missing> (raw)
In-Reply-To: <marc-lartc-103926701306950@msgid-missing>
Abraham van der Merwe writes:
> Hi Don!
>
> > > 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).
A small detail: what are "small packet fifos"? You mean fifos that
can only hold a small number of packets? Or fifos that only hold
packets with small numbers of bytes?
> > 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.
>
> The problem is that with 200ms the packet loss is so much that the link is
> effectively useless (90% packet loss). As soon as I make the queue big
> enough to not drop significant amounts of packets, the latency goes way up
> (>3 secs).
I don't understand the connection between 200ms and packet loss.
If you make the queue small (in packet capacity) then worst case
latency decreases. Packet loss occurs in either case whenever a
packet arrives and the queue is full.
If you try to send at a higher rate than allowed then you will fill
the queue in either case (a small queue more quickly, of course),
and from then on you will lose packets. If you send packets at twice
the allowed rate you lose half of them, if you send at 10 times the
allowed rate you lose 90%.
The fact that you're losing lots of packets, though, indicates to me
that you're acting like an attacker, and dropping most of that traffic
is therefore exactly the right thing to do.
If you were using a correctly working tcp it would not continue to
send at 10 times the allowed rate. It would notice that packets were
being lost and would slow down until the loss rate became very small.
Similarly, I don't understand the latency issue. An application that
cares about latency will not create a large backlog.
What is this application that is sending faster than the link allows
and wants a low latency, and why is it misbehaving?
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
next prev parent reply other threads:[~2002-12-09 16:44 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
2002-12-09 16:11 ` Abraham van der Merwe
2002-12-09 16:44 ` Don Cohen [this message]
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-103945253522230@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.