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/
next prev 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.