All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Furniss <andy.furniss@dsl.pipex.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] urgent question about tcng!
Date: Wed, 27 Apr 2005 21:22:33 +0000	[thread overview]
Message-ID: <42700299.7030008@dsl.pipex.com> (raw)
In-Reply-To: <PDC8QMTiuEmmfnUmLbx00000035@pdc.ikarus.local>

Thomas Mandl wrote:
> Hello List,
> I'm new to QoS/tcng/HTB and friends, so please forgive me if my question
> might be silly...
> After having read lots of HowTo documents I'm totally confused...
> 
> The Challenge:
> =======
> I'll have to deploy several "mirror" download servers (Linux) which must be
> able to handle a huge number of HTTP download requests (about 10k to 20k
> unicast requests per server within 120 min.) which will hit my servers . The
> mirror servers will be connected with 100MBit to the Internet backbone. Each
> "client" will download between 7MB up to 30MB per request. The download
> mirror servers will be directly attached to the Internet (no FW or router
> between, which could handle QoS for me). Of course will these download
> mirrors be specially hardened :-)
> 
> The Idea:
> ====> I can not handle all the traffic at once without QoS, so I thought it should
> be possible to establish a traffic control mechanism to guarantee bandwith
> for each client download (e.g. 256kbps CIR up to 512kbps ceil). This should
> allow me, to "serve" all clients within 120 min, before a new download wave
> will hit my servers. If the available bandwith for HTTP traffic is used,
> clients shall not be able to start a download, until some bandwith is freed
> by another client who finished a download. 
> 
> Note: I would rather go with "tcng" than with the old "tc".
> 
> The Problem:
> ======
> While playing with tcng and HTB I managed to shape traffic (to limit the
> total bandwith for HTTP traffic to e.g. 50Mbps) but I did not manage to
> write a tcng configuration which guarantees a certain bandwith per client
> request. I must be able to assign (and guarantee) a defined bandwith to a
> client request, to make the downloads more predictable. My experiments so
> far only allowed me to limit e.g. HTTP traffic, which then was equally
> distributed to the number of clients, but this led to the usual "traffic
> jam" when too many clients initiated a simultanes download.
> 
> Can anybody please assist me, or does anybody have a working "tcng" config
> file to do the job. Additional readings/comments/links (beside those listed
> in the LDB/Linux Traffic Control Howtos are also welcome.)

Wang Jian posted a perflow queue recently -

http://mailman.ds9a.nl/pipermail/lartc/2005q2/015381.html

It is the sort of thing you need if you can't do it with apache as 
recommended.

Andy.

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

  parent reply	other threads:[~2005-04-27 21:22 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-27 16:11 [LARTC] urgent question about tcng! Thomas Mandl
2005-04-27 16:17 ` Sylvain BERTRAND
2005-04-27 18:25 ` Jason Boxman
2005-04-27 21:22 ` Andy Furniss [this message]
2005-04-28  7:34 ` AW: " Thomas Mandl
2005-05-03 13:45 ` Andy Furniss
2005-05-03 14:42 ` Andy Furniss
2005-05-03 23:05 ` AW: " Thomas Mandl
2005-05-04 14:23 ` Andy Furniss

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=42700299.7030008@dsl.pipex.com \
    --to=andy.furniss@dsl.pipex.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.