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] TCP Rate Control
Date: Thu, 15 May 2003 19:15:26 +0000	[thread overview]
Message-ID: <marc-lartc-105302621509010@msgid-missing> (raw)
In-Reply-To: <marc-lartc-105291155220508@msgid-missing>

> > But I'm still intested in the comparision :)
>
> It's you quest for the truth that endears you to all of us. :)
>
> Googling for "tcp rate control" would lead you to a lot of material,
> including documents "proving" queuing is better than rate control.
>
> Here's the test jig I plan to setup...
>
> Windows client running Gozilla, for crude throughput reporting
>
> |(1)
>
> ->"Gateway" m/c with two NICs [RTL8139 based] running nisnet and tbf,
> iptraf and MRTG--
>
>                  |(2)
>
>                  ->Linux based FTP/HTTP Server
>
> I will try with sustained downloads, perhaps 1GB. The tbf would be set
> to limit at 100kbps.
>
>  From what I expect, I would only get 100kbps on the windows client m/c,
> i.e. at point (1). But between the gateway and server, i.e. point (2),
> the bandwidth consumption would be higher. How much higher I don't know
> - it might be anything from 100kbps to NIC speed. If it is within a 5%
> tolerance, i.e. from 95kbps to 100kbps, I would say that the world is a
> great place and I am happy to be here...i.e. queuing would have achieved
> what I want.
>
> But, I suspect the difference would be much more...
Why?  What will happen with the packets that are arrived too much?  Do you 
really think they all will be lost?  
I'm no tcp specialist, but the traffic at 2 will be exactly 100kbps.  I see it 
like this : client starts download and goes faster and faster.  When it 
reaches 100kbps, all tokens in the bucket are used.  After that, the gateway 
starts delaying packets.  From the tbf manpage :

If no tokens are available, packets are queued, up to a configured limit

Packets are not dropped but delayed.  At that time, the server noticed that 
the packets are not arriving at a speed > 100kbps (they are queued in the 
bucket) at the client and throttle downs.  When the server throttles down 
below 100kbps, the queued packets can be send again because there are tokens 
available in the bucket.  So after some time it will be stable at 100kbps.

Again, I don't know how tbf works.  This is just the way I think it works.

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-05-15 19:15 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-14 11:36 [LARTC] TCP Rate Control Varun Varma
2003-05-14 18:00 ` Stef Coene
2003-05-14 19:59 ` Brandis Jaroslav
2003-05-14 20:09 ` Stef Coene
2003-05-14 23:06 ` Jose Luis Domingo Lopez
2003-05-15 17:06 ` Stef Coene
2003-05-15 17:53 ` Stef Coene
2003-05-15 17:53 ` Varun Varma
2003-05-15 18:34 ` Varun Varma
2003-05-15 19:15 ` Stef Coene [this message]
2003-05-15 19:45 ` Stef Coene
2003-05-15 21:11 ` Varun Varma
2003-05-16  9:20 ` Stef Coene

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