All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dimitris Kotsonis <jnk@comkey.spark.net.gr>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Shaping traffic on heavily oversubscribed links?
Date: Mon, 06 Dec 2004 11:54:56 +0000	[thread overview]
Message-ID: <41B44890.4090401@comkey.spark.net.gr> (raw)
In-Reply-To: <41A5A31B.8010901@expertron.co.za>

Justin Schoeman wrote:

> Hi all,
>
> I am having some fun with traffic shaping, and have run into an 
> interesting situation.  Here is South Africa, most internet links are 
> heavily oversubscribed, which means that in most cases the local link 
> is _not_ the bottleneck, and shaping on the local link does not help 
> that much...
>

We have the same problem in DSL lines here in Greece.

I have found that while the average efective speed on such lines varies, 
tha average rate of packets is more or less constant. I have a theory 
for this. I believe that the routers that forward the traffic on 
congested lines - on ISPs and on the ATM circuits at the telcoms - don't 
take the extra time needed to calculate the size of the packets and 
distribute the traffic on a per packet basis. This leads to a 'fairness' 
among the end receivers based on packets/sec instead of  bandwidth.

To be more specific. In my ADSL line I usually achieve between 20-30 pps 
(measured with MRTG). With an average packet size of 1500 this is 20-45 
kbytes/sec. But packets sizes close to the MTU are found on single 
ftp/http connections and pretty much nowehere else. Packet sizes of 400 
to 500 are more realistic, especially when p2p programs are involved. 
20-30 packets give 8-10kbytes/sec. You can expect even less when using 
voip programs which utilize smaller packets.

If you find that single a FTP session tends to get more bandwidth thatn 
p2p programs or multiuser traffic then you have a simillar problem to 
our own. I would suggest that you setup MRTG to monitor packets to 
research further into this.



> Does anybody have some tips on shaping such links?  How can you get 
> interractive traffic if you don't know how much bandwidth to reserve 
> for it? How can you give fair access to a link if you don't know what 
> the link capacity is?
>

Well, I am working on one. Since I can't shape bandwidth because it 
flactuates erratically with time and usage I decided to shape packets. I 
have created a new queueing discipline based on TBF which uses packets 
instead of bytes for its tokens and I am allocating a constant 
packet/sec rate on each user of my ADSL line. A better solution would be 
to create an HTB alike packet-based qdisc for dynamic shaping.

If you find that you have the some problem as me and you want to 
experiment with a packet-based TBF qdisc I can send you a patch for 
linux-2.6.8 and iproute2 in this list.

I would like to here your thought on this anyway ...

Dimitris



_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

  parent reply	other threads:[~2004-12-06 11:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-25  9:17 [LARTC] Shaping traffic on heavily oversubscribed links? Justin Schoeman
2004-11-25 18:01 ` Chris Bennett
2004-11-25 20:48 ` Rick Marshall
2004-11-26  9:00 ` Justin Schoeman
2004-11-29  2:47 ` Jason Boxman
2004-12-06 11:54 ` Dimitris Kotsonis [this message]
2005-01-02  1:07 ` 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=41B44890.4090401@comkey.spark.net.gr \
    --to=jnk@comkey.spark.net.gr \
    --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.