From: "Mihai Vlad" <mihaivlad@web-profile.net>
To: lartc@vger.kernel.org
Subject: RE: [LARTC] Split bandwidth equally per IP
Date: Wed, 17 Dec 2003 16:56:06 +0000 [thread overview]
Message-ID: <marc-lartc-107168208018261@msgid-missing> (raw)
In-Reply-To: <marc-lartc-107056586923918@msgid-missing>
http://www.digriz.org.uk/jdg-qos-script/
This is in fact the link... My mistake.
I promised I will keep you informed with my progress in splitting the
bandwidth equally per IP. Unfortunately, for some odd reason Jim diGriz's
script did not work as I expected...
At that moment I was sure that esfq is uselsss, until I created my own
script and it worked surprisingly well :) The error as I spotted using
iptraf as a monitor was about 0.2 - 0.4 Kbytes which is very very small.
I spotted also a little "malfunction"... Maybe you can tell me what's wrong.
Imagine a 128 kbits (not Kbytes... a verry small) bandwidth that I have to
split for 12 clients in my LAN. Using the "default" HTB would result in a
r2q error and a small calculated quantum. So, as Stef sugested I hardcoded
the quantum parameter for all the 12 leaf classes:
$TC class add dev $LAN_IFACE parent 1:12 classid 1:121 htb rate 8kbit ceil
96kbit quantum 1500
I noticed that changing the rate parameter will not change the guaranteed
bandwith. So here are some questions:
1. Is "quantum" the real parameter related with the guaranteed bandwidth?
2. Is the sum of all "leaf class quantums" relevant? (As far as I understood
the sum of all rates in the leaf classes must not exceed the parent class
rate...)
I went further and changed the quantum from diffent clients from 1500 to
3000 (based on my knowledge this would mean double guaranteed bandwidth)
I set up a liitle test. I started 2 client computers and made them download
the same file with the same download manager. Client_1 had a 3000 quantum
and Client_2 had a 1500 quantum. The rates observed with iptraf were
10Kbytes for Client_1 and 5Kbytes for Client_2, which was the expected
result.
Another test with the quantum of Client_1 set to 15000\x1500*10.
The expected result was to have a bandwith for Client_1 10 times greater
than the one for Client_2... The real results told me that whatever chenges
are made for the quantum, the Client_2 bandwith won't fall below 4Kbytes...
3. Can you tell me why the Cllient_2 bandwidth will not decrease below 4
Kbytes?
Thanks again for your time :)
Mihai Vlad
-----Original Message-----
From: Fabian Gervan [mailto:fabian1@diarioc.com.ar]
Sent: Wednesday, December 17, 2003 4:59 PM
To: Mihai Vlad
Subject: Re[2]: [LARTC] Split bandwidth equally per IP
Hello Mihai,
MV> It seems that Jim diGriz already accomplished that, but I did not read
the
MV> entire page to see that there was a script to download. My mistake :)
MV> For those who don't know yet, here is the link:
MV> http://www.digriz.org.uk/jdg-qos-script/index.htm
404 error.
Fabian
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
prev parent reply other threads:[~2003-12-17 16:56 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-04 18:52 [LARTC] Split bandwidth equally per IP Mihai Vlad
2003-12-04 19:44 ` Stef Coene
2003-12-05 15:08 ` jzeeff
2003-12-05 15:19 ` jzeeff
2003-12-05 15:57 ` Mihai Vlad
2003-12-05 17:02 ` Martin A. Brown
2003-12-05 17:50 ` jzeeff
2003-12-05 22:45 ` Mihai Vlad
2003-12-07 0:12 ` jzeeff
2003-12-07 6:21 ` 'Martin A. Brown'
2003-12-07 6:23 ` 'Martin A. Brown'
2003-12-07 8:30 ` Mihai Vlad
2003-12-07 9:32 ` Chijioke Kalu
2003-12-07 21:19 ` Nickola Kolev
2003-12-17 16:56 ` Mihai Vlad [this message]
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-107168208018261@msgid-missing \
--to=mihaivlad@web-profile.net \
--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.