Re: [LARTC] ESFQ: request for user input
Patrick McHardy wrote: > Corey Hickey wrote: >> Patrick McHardy wrote: Should ESFQ be merged into SFQ or remain as a separate qdisc? >>> I've CCed netdev. I think merging parts of ESFQ (dynamic depth and >>> flow number) would make a lot of sense, but I'm intending to submit >>> an alternative to the ESFQ hashing scheme for 2.6.23: >>> >>> http://www.mail-archive.com/[EMAIL PROTECTED]/msg39156.html >>> >> Nice. I wasn't aware of that. Your patch looks like it supersedes ESFQ's >> hashing, so, if it gets applied, that already removes a large chunk of >> the differences between SFQ and ESFQ. >> >> If I don't hear any opposition, then I'll keep an eye out for when your >> patch gets accepted (assuming it does) and then submit patch(es) porting >> the rest of ESFQ's features to SFQ. >> > > I think it would be best if you would start posting patches > to add the missing features (without the hash changes) to SFQ, > if you're quick this may already go in during the 2.6.23 merge > window. My changes are mostly independant of yours, if there > are any clashes the one who goes last will just have to rediff > their patches :) > > Since you need to pass additional parameters to SFQ for your > changes, have a look at my rtnetlink compat attribute patch: > > http://article.gmane.org/gmane.linux.network/64851 Ok, I'll work on it later. Thanks. -Corey ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ESFQ: request for user input
Corey Hickey wrote: Patrick McHardy wrote: Should ESFQ be merged into SFQ or remain as a separate qdisc? I've CCed netdev. I think merging parts of ESFQ (dynamic depth and flow number) would make a lot of sense, but I'm intending to submit an alternative to the ESFQ hashing scheme for 2.6.23: http://www.mail-archive.com/[EMAIL PROTECTED]/msg39156.html Nice. I wasn't aware of that. Your patch looks like it supersedes ESFQ's hashing, so, if it gets applied, that already removes a large chunk of the differences between SFQ and ESFQ. If I don't hear any opposition, then I'll keep an eye out for when your patch gets accepted (assuming it does) and then submit patch(es) porting the rest of ESFQ's features to SFQ. I think it would be best if you would start posting patches to add the missing features (without the hash changes) to SFQ, if you're quick this may already go in during the 2.6.23 merge window. My changes are mostly independant of yours, if there are any clashes the one who goes last will just have to rediff their patches :) Since you need to pass additional parameters to SFQ for your changes, have a look at my rtnetlink compat attribute patch: http://article.gmane.org/gmane.linux.network/64851 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ESFQ: request for user input
Patrick McHardy wrote: > Corey Hickey wrote: >> Hello, >> >> I haven't been keeping up with sending ESFQ [ANNOUNCE] messages to this >> list, but I've still been working on the patch. If you're curious about >> recent changes, take a look at the home page, ChangeLog, and README: >> >> http://fatooh.org/esfq-2.6/ >> http://fatooh.org/esfq-2.6/current/ChangeLog >> http://fatooh.org/esfq-2.6/current/README >> >> Meanwhile, I'm interested in finally getting ESFQ included in the Linux >> kernel. Before I start sending patches and requesting maintainer review, >> however, there's one question I want to ask current or potential users >> of SFQ and ESFQ: >> >> Should ESFQ be merged into SFQ or remain as a separate qdisc? > > I've CCed netdev. I think merging parts of ESFQ (dynamic depth and > flow number) would make a lot of sense, but I'm intending to submit > an alternative to the ESFQ hashing scheme for 2.6.23: > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg39156.html Nice. I wasn't aware of that. Your patch looks like it supersedes ESFQ's hashing, so, if it gets applied, that already removes a large chunk of the differences between SFQ and ESFQ. If I don't hear any opposition, then I'll keep an eye out for when your patch gets accepted (assuming it does) and then submit patch(es) porting the rest of ESFQ's features to SFQ. I just subscribed myself to netdev. > I have enough trust in ESFQ's stability that I don't think we need > a new qdisc for this and could merge it in SFQ (and the "uses only > 1 page" justification isn't true anymore anyway), but I also > wouldn't mind adding a new qdisc. Thanks for the trust; I'm sure that the patches will have to undergo some cleanup either way, considering my newbieness to kernel development. -Corey ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ESFQ: request for user input
Corey Hickey wrote: > Hello, > > I haven't been keeping up with sending ESFQ [ANNOUNCE] messages to this > list, but I've still been working on the patch. If you're curious about > recent changes, take a look at the home page, ChangeLog, and README: > > http://fatooh.org/esfq-2.6/ > http://fatooh.org/esfq-2.6/current/ChangeLog > http://fatooh.org/esfq-2.6/current/README > > Meanwhile, I'm interested in finally getting ESFQ included in the Linux > kernel. Before I start sending patches and requesting maintainer review, > however, there's one question I want to ask current or potential users > of SFQ and ESFQ: > > Should ESFQ be merged into SFQ or remain as a separate qdisc? I've CCed netdev. I think merging parts of ESFQ (dynamic depth and flow number) would make a lot of sense, but I'm intending to submit an alternative to the ESFQ hashing scheme for 2.6.23: http://www.mail-archive.com/[EMAIL PROTECTED]/msg39156.html I have enough trust in ESFQ's stability that I don't think we need a new qdisc for this and could merge it in SFQ (and the "uses only 1 page" justification isn't true anymore anyway), but I also wouldn't mind adding a new qdisc. > Note that I can't promise either is an option, since I haven't queried > any maintainers yet; I'd rather have a clear idea of what is more > desirable to the users before I propose anything. Of course, if any > maintainers read this, I would value their input at this point as well. > > Here are some advantages and disadvantages of merging ESFQ with SFQ. > Please correct me or let me know of any others you think of. > > ---Advantages--- > * There's nothing radically different about ESFQ. A separate sch_esfq.c > would duplicate lots of the code in sch_sfq.c. > * Current users of SFQ would benefit from the better hashing of using > jhash. Other than that, the default parameters of ESFQ are the same > as SFQ's hardcoded values, so ESFQ would be a drop-in replacement. > * Having two similar-looking similarly-functioning qdiscs could be > confusing for new users. > > ---Disadvantages--- > * SFQ has been stable for years; it may be undesirable to make changes > that could potentially introduce bugs. > * ESFQ is marginally slower than SFQ (although I haven't been able to > measure a practical difference; if someone has benchmark tips I'll try > them). ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ESFQ: request for user input
Corey Hickey wrote: Meanwhile, I'm interested in finally getting ESFQ included in the Linux kernel. Patrick McHardy recently changed sfq to be more like esfq. http://marc.info/?l=linux-netdev&m=118051806814780&w=2 Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] ESFQ: request for user input
Hello, I haven't been keeping up with sending ESFQ [ANNOUNCE] messages to this list, but I've still been working on the patch. If you're curious about recent changes, take a look at the home page, ChangeLog, and README: http://fatooh.org/esfq-2.6/ http://fatooh.org/esfq-2.6/current/ChangeLog http://fatooh.org/esfq-2.6/current/README Meanwhile, I'm interested in finally getting ESFQ included in the Linux kernel. Before I start sending patches and requesting maintainer review, however, there's one question I want to ask current or potential users of SFQ and ESFQ: Should ESFQ be merged into SFQ or remain as a separate qdisc? Note that I can't promise either is an option, since I haven't queried any maintainers yet; I'd rather have a clear idea of what is more desirable to the users before I propose anything. Of course, if any maintainers read this, I would value their input at this point as well. Here are some advantages and disadvantages of merging ESFQ with SFQ. Please correct me or let me know of any others you think of. ---Advantages--- * There's nothing radically different about ESFQ. A separate sch_esfq.c would duplicate lots of the code in sch_sfq.c. * Current users of SFQ would benefit from the better hashing of using jhash. Other than that, the default parameters of ESFQ are the same as SFQ's hardcoded values, so ESFQ would be a drop-in replacement. * Having two similar-looking similarly-functioning qdiscs could be confusing for new users. ---Disadvantages--- * SFQ has been stable for years; it may be undesirable to make changes that could potentially introduce bugs. * ESFQ is marginally slower than SFQ (although I haven't been able to measure a practical difference; if someone has benchmark tips I'll try them). -Corey ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ESFQ and bridges
Roberto Pereyra wrote: > Hi > > ESFQ works with bridges ? ...just as well as any other qdisc... -Corey ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] ESFQ and bridges
Hi ESFQ works with bridges ? Thanks a lot roberto -- Ing. Roberto Pereyra ContenidosOnline Looking for Linux Virtual Private Servers ? Click here: http://www.spry.com/hosting-affiliate/scripts/t.php?a_aid=426&a_bid=56 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ESFQ not so fair?
Corey Hickey napisał(a): Using jhash is a probably a good idea, the "improved" hash is broken and will cause reordering in some circumstances: return (h - q->dyn_min) * (q->hash_divisor - 1) / q->dyn_range; dyn_min, dyn_max and dyn_range, as their name suggests, are adjusted dynamically, so the hash function changes whenever one of these values changes, resulting in reordering of packets belonging to a single flow. That should stabilize after it's been running a while and has seen the normal range of IP addresses. Anyway, I agree, it's not very good. I am changing size of HTB queue at 01:00 AM and then back at 06:00 AM. So it is quite possible that hash used by esfq will never go stable? If I know range of input values will hardcoding that into esfq help? Or maybe there is something similair to esfq with direct hash but a larger one (16 bits should be enough). I don't care about memory usage, mostly important is performance. I am going to get uplink from another company and having another few thousands of HTB qdisc is not wise idea :-). -- Michał Margula, [EMAIL PROTECTED], http://alchemyx.uznam.net.pl/ "W życiu piękne są tylko chwile" [Ryszard Riedel] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ESFQ not so fair?
Patrick McHardy wrote: Andy Furniss wrote: Corey Hickey changed his esfq to use jhash for dst/src/fw - copy of his announce below. Andy. Corey Hickey wrote: So, I wrote an alternative hash function. It's quite simple, and as long as the range of input values is smaller than the hash table (default 1024, up to 16384), collisions will not happen at all. See the updated README file for more details. Using jhash is a probably a good idea, the "improved" hash is broken and will cause reordering in some circumstances: return (h - q->dyn_min) * (q->hash_divisor - 1) / q->dyn_range; dyn_min, dyn_max and dyn_range, as their name suggests, are adjusted dynamically, so the hash function changes whenever one of these values changes, resulting in reordering of packets belonging to a single flow. That should stabilize after it's been running a while and has seen the normal range of IP addresses. Anyway, I agree, it's not very good. Working on ESFQ some more has been on my long-term TODO list, but what with getting distracted by mplayer development I didn't get around to it... and now I have 1.2 real jobs and 1.0 girlfriends and don't have time for much programming. :) If any of you want to send patches to this list and they don't look bad to other readers of the list I'll happily apply them and make a new release. Other than that, I can't help you much for now. Thanks, Corey ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ESFQ not so fair?
Michał Margula wrote: Andy Furniss napisał(a): Corey Hickey changed his esfq to use jhash for dst/src/fw - copy of his announce below. Andy. Thanks, but I am already using his patch :-). It happens with that patch, I haven't tried original version at all. Ahh OK - looks like Patrick spotted the problem I guess Corey will see this thread. His limit is 2^14 though, which is why I thought you must be using a different one. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ESFQ not so fair?
Patrick McHardy wrote: Andy Furniss wrote: Corey Hickey changed his esfq to use jhash for dst/src/fw - copy of his announce below. Using jhash is a probably a good idea, the "improved" hash is broken and will cause reordering in some circumstances: return (h - q->dyn_min) * (q->hash_divisor - 1) / q->dyn_range; dyn_min, dyn_max and dyn_range, as their name suggests, are adjusted dynamically, so the hash function changes whenever one of these values changes, resulting in reordering of packets belonging to a single flow. Oops I thought he did use jhash don't know where I got that from. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ESFQ not so fair?
Andy Furniss wrote: > Corey Hickey changed his esfq to use jhash for dst/src/fw - copy of his > announce below. > > Andy. > > Corey Hickey wrote: >> So, I wrote an alternative hash function. It's quite simple, and as long >> as the range of input values is smaller than the hash table (default > 1024, >> up to 16384), collisions will not happen at all. See the updated README >> file for more details. Using jhash is a probably a good idea, the "improved" hash is broken and will cause reordering in some circumstances: return (h - q->dyn_min) * (q->hash_divisor - 1) / q->dyn_range; dyn_min, dyn_max and dyn_range, as their name suggests, are adjusted dynamically, so the hash function changes whenever one of these values changes, resulting in reordering of packets belonging to a single flow. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ESFQ not so fair?
Andy Furniss napisał(a): Corey Hickey changed his esfq to use jhash for dst/src/fw - copy of his announce below. Andy. Thanks, but I am already using his patch :-). It happens with that patch, I haven't tried original version at all. -- Michał Margula, [EMAIL PROTECTED], http://alchemyx.uznam.net.pl/ "W życiu piękne są tylko chwile" [Ryszard Riedel] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ESFQ not so fair?
Michał Margula wrote: Hello! I am using since yesterday ESFQ instead of N HTB queues. It mostly works OK, but when somebody is using one single sesion (for example downloading file via FTP), it gets weird speed. For example it is 20 kilobytes pres second, then drops down to 9, then 20 again, and then slowly to 0 and stops. But when using download accelererator of some kind or bittorrent client which uses many connections, speed seems to be stable. I am using esfq that way: qdisc add dev eth0 parent 1:4 handle 4:0 esfq perturb 600 hash fwmark divisor 13 qdisc add dev eth1 parent 1:2 handle 2:0 esfq perturb 600 hash dst divisor 13 On eth0 every IP is marked with different value by IPMARK module. On eth1 it is not necessary so I use dst hash. I have more values than 2^13 so I can't use direct hash. Any ideas? Is it possible to use bigger divisor or algorithm is not designed to deal with bigger hash? Any ideas will be appreciated! Corey Hickey changed his esfq to use jhash for dst/src/fw - copy of his announce below. Andy. Corey Hickey wrote: > In a recent thread on this list, Robert Kurjata provided me a patch to add > hashing by iptables mark to the Linux 2.4 version of ESFQ. Thanks to that > contribution, I was able to easily add support to the 2.6 port I maintain. > > I found out, however, that the existing hash algorithm results in a lot of > colllisions when the range of hashed values is small. The purturbation > spreads the collisions out a little, but the result still wasn't very > fair, especially when hashing only three fwmark values: 0, 1 and 2. > > So, I wrote an alternative hash function. It's quite simple, and as long > as the range of input values is smaller than the hash table (default 1024, > up to 16384), collisions will not happen at all. See the updated README > file for more details. > > Home page: > http://fatooh.org/esfq-2.6/ > > Direct URL: > http://fatooh.org/esfq-2.6/esfq-2.6.13.tar.gz > > README (also available in the tar.gz): > http://fatooh.org/esfq-2.6/current/README > > Try it out, have fun, and if you find a bug or have a suggestion please > send me an email. > > -Corey ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] ESFQ not so fair?
Hello! I am using since yesterday ESFQ instead of N HTB queues. It mostly works OK, but when somebody is using one single sesion (for example downloading file via FTP), it gets weird speed. For example it is 20 kilobytes pres second, then drops down to 9, then 20 again, and then slowly to 0 and stops. But when using download accelererator of some kind or bittorrent client which uses many connections, speed seems to be stable. I am using esfq that way: qdisc add dev eth0 parent 1:4 handle 4:0 esfq perturb 600 hash fwmark divisor 13 qdisc add dev eth1 parent 1:2 handle 2:0 esfq perturb 600 hash dst divisor 13 On eth0 every IP is marked with different value by IPMARK module. On eth1 it is not necessary so I use dst hash. I have more values than 2^13 so I can't use direct hash. Any ideas? Is it possible to use bigger divisor or algorithm is not designed to deal with bigger hash? Any ideas will be appreciated! -- Michał Margula, [EMAIL PROTECTED], http://alchemyx.uznam.net.pl/ "W życiu piękne są tylko chwile" [Ryszard Riedel] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] esfq ? or wrr ?
Corey Hickey wrote:
>
> I still maintain ESFQ; the latest version is at:
> http://fatooh.org/esfq-2.6/
>
> This would be an appropriate time to ask:
> Does anybody have any fixes for or improvements to ESFQ that I don't
> know about? My patch doesn't have anything revolutionary -- I've been
> merely keeping Alexander Clouter's 2.6 port in sync with the upstream
> changes to SFQ.
>
> -Corey
1) I'd like for your code to support kernel version 2.4! It is crazy
that there are two branches of ESFQ.
2) ESFQ should be able to match a firewall mark, dport and sport. All
except CLASSIC should understand NOT ("! sport 22").
3) The documentation should be improved.
--
gypsy
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] esfq ? or wrr ?
-> I think it depends on the type of traffic you're -> expecting from the different users. If you're -> expecting very similar patterns of behaviour, then my -> guess would be ESFQ would be the better. -> -> If, on the other hand, the network load is going to -> shift over time, between the users, then WRR would -> seem the more logical choice. -> -> You might also want to look at HFSC (Heirarchical Fair -> Service Curve) - it's possible you might be able to -> get what you want from the single algorithm, rather -> than piping through several. The fewer layers you -> have, the less latency you'll introduce. HFSC also has -> the advantage that it is standard in the kernel, so -> likely has better testing. OK. I've read some domcumments about HFSC, but at the momment I understand it. Can you post me a good tutorial about HFSC ? thank you. -> -> ESFQ and WRR have been forward-ported, well, -> sometimes, but only the combined -qos patch seems to -> be current - the individual patches don't seem to be -> maintained at all. -> -> I would like to see the patches cleaned up (as -> necessary) then submitted for merging into the -> mainstream kernel. Linux' QoS code is in frankly -> horrible shape at the moment, so anything that stirred -> interest in it would almost have to be a good thing, -> even if the patches themselves didn't get included any -> time soon. -> -> --- LinuXKiD <[EMAIL PROTECTED]> wrote: -> -> > Hi -> > -> > If I have a HTB class with 128kbit, and I want to -> > put "N" users in that class ( in order to share -> > bandwidth fairly ) , -> > -> > which is better for me ? esfq (hash dst) or wrr ? -> > -> > I would attach esfq or wrr to HTB parent class. -> > -> > Also I've readed on Jim script that over WRR put -> > a RED qdisc, but I don't understand it. -> > -> > bests -> > -> > andres -> > ___ -> > LARTC mailing list -> > LARTC@mailman.ds9a.nl -> > -> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -> > -> -> -> -> -> __ -> Start your day with Yahoo! - Make it your home page! -> http://www.yahoo.com/r/hs ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re[2]: [LARTC] esfq ? or wrr ?
[cut]
CH> This would be an appropriate time to ask:
CH> Does anybody have any fixes for or improvements to ESFQ that I don't
CH> know about? My patch doesn't have anything revolutionary -- I've been
CH> merely keeping Alexander Clouter's 2.6 port in sync with the upstream
CH> changes to SFQ.
Yes :)
Some time ago I needed to do sfq between different users in NAT-ed
environment. The users were marked by firewall marks, so I've done a
little change to esfq just adding new hash source - nfmark.
It was done for iproute2-ss020116 and kernel 2.4.26, so it's a little
old. The kernel part is still (I think, not tried) operational.
I think it makes esfq more flexible.
The patches for individual files are below.
---KERNEL-PATCH---
--- sch_esfq.c.old 2004-04-21 18:00:42.0 +0200
+++ sch_esfq.c 2004-01-07 21:39:24.0 +0100
@@ -117,6 +117,7 @@
{
u32 h, h2;
u32 hs;
+ u32 nfm;
switch (skb->protocol) {
case __constant_htons(ETH_P_IP):
@@ -124,6 +125,7 @@
struct iphdr *iph = skb->nh.iph;
h = iph->daddr;
hs = iph->saddr;
+ nfm = skb -> nfmark;
h2 = hs^iph->protocol;
if (!(iph->frag_off&htons(IP_MF|IP_OFFSET)) &&
(iph->protocol == IPPROTO_TCP ||
@@ -137,6 +139,7 @@
struct ipv6hdr *iph = skb->nh.ipv6h;
h = iph->daddr.s6_addr32[3];
hs = iph->saddr.s6_addr32[3];
+ nfm = skb->nfmark;
h2 = hs^iph->nexthdr;
if (iph->nexthdr == IPPROTO_TCP ||
iph->nexthdr == IPPROTO_UDP ||
@@ -148,6 +151,7 @@
h = (u32)(unsigned long)skb->dst;
hs = (u32)(unsigned long)skb->sk;
h2 = hs^skb->protocol;
+ nfm = skb->nfmark;
}
switch(q->hash_kind)
{
@@ -157,6 +161,8 @@
return esfq_hash_u32(q,h);
case TCA_SFQ_HASH_SRC:
return esfq_hash_u32(q,hs);
+ case TCA_SFQ_HASH_FWMARK:
+ return esfq_hash_u32(q,nfm);
default:
if (net_ratelimit())
printk(KERN_DEBUG "esfq unknown hash method, fallback
to classic\n");
--- pkt_sched.h.old 2005-10-15 09:49:10.0 +0200
+++ pkt_sched.h 2005-10-15 09:48:31.0 +0200
@@ -162,6 +162,7 @@
TCA_SFQ_HASH_CLASSIC,
TCA_SFQ_HASH_DST,
TCA_SFQ_HASH_SRC,
+ TCA_SFQ_HASH_FWMARK,
};
struct tc_sfq_qopt
IPROUTE--
--- q_esfq.c.old2005-10-15 09:57:08.0 +0200
+++ q_esfq.c2005-10-15 09:51:36.0 +0200
@@ -30,7 +30,7 @@
{
fprintf(stderr, "Usage: ... esfq [ perturb SECS ] [ quantum BYTES ] [
depth FLOWS ]\n\t[ divisor HASHBITS ] [ limit PKTS ] [ hash HASHTYPE]\n");
fprintf(stderr,"Where: \n");
- fprintf(stderr,"HASHTYPE := { classic | src | dst }\n");
+ fprintf(stderr,"HASHTYPE := { classic | src | dst | fwmark }\n");
}
#define usage() return(-1)
@@ -95,6 +95,9 @@
} else
if(strcmp(*argv,"src") == 0) {
opt.hash_kind= TCA_SFQ_HASH_SRC;
+ } else
+ if(strcmp(*argv,"fwmark") == 0) {
+ opt.hash_kind= TCA_SFQ_HASH_FWMARK;
} else {
fprintf(stderr, "Illegal \"hash\"\n");
explain();
@@ -148,6 +151,9 @@
case TCA_SFQ_HASH_SRC:
fprintf(f,"src");
break;
+ case TCA_SFQ_HASH_FWMARK:
+ fprintf(f,"fw");
+ break;
default:
fprintf(f,"Unknown");
}
--
Greetings,
Robert Kurjata
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] esfq ? or wrr ?
Jonathan Day wrote: > ESFQ and WRR have been forward-ported, well, > sometimes, but only the combined -qos patch seems to > be current - the individual patches don't seem to be > maintained at all. I still maintain ESFQ; the latest version is at: http://fatooh.org/esfq-2.6/ These days there hasn't been much to do; as far as I know the patches I made on 2005-03-31 still work fine with the latest kernel and iproute2. I just put a note about that on my ESFQ page. > I would like to see the patches cleaned up (as > necessary) then submitted for merging into the > mainstream kernel. Linux' QoS code is in frankly > horrible shape at the moment, so anything that stirred > interest in it would almost have to be a good thing, > even if the patches themselves didn't get included any > time soon. That would be nice. One or two other people have approached me about trying to get ESFQ merged, but I just haven't gotten around to it. When I've finished my current project I'll get in touch with Stephen Hemminger and see what must be done to get the iproute2 patch merged, and then take it from there. This would be an appropriate time to ask: Does anybody have any fixes for or improvements to ESFQ that I don't know about? My patch doesn't have anything revolutionary -- I've been merely keeping Alexander Clouter's 2.6 port in sync with the upstream changes to SFQ. -Corey ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] esfq ? or wrr ?
I think it depends on the type of traffic you're expecting from the different users. If you're expecting very similar patterns of behaviour, then my guess would be ESFQ would be the better. If, on the other hand, the network load is going to shift over time, between the users, then WRR would seem the more logical choice. You might also want to look at HFSC (Heirarchical Fair Service Curve) - it's possible you might be able to get what you want from the single algorithm, rather than piping through several. The fewer layers you have, the less latency you'll introduce. HFSC also has the advantage that it is standard in the kernel, so likely has better testing. ESFQ and WRR have been forward-ported, well, sometimes, but only the combined -qos patch seems to be current - the individual patches don't seem to be maintained at all. I would like to see the patches cleaned up (as necessary) then submitted for merging into the mainstream kernel. Linux' QoS code is in frankly horrible shape at the moment, so anything that stirred interest in it would almost have to be a good thing, even if the patches themselves didn't get included any time soon. --- LinuXKiD <[EMAIL PROTECTED]> wrote: > Hi > > If I have a HTB class with 128kbit, and I want to > put "N" users in that class ( in order to share > bandwidth fairly ) , > > which is better for me ? esfq (hash dst) or wrr ? > > I would attach esfq or wrr to HTB parent class. > > Also I've readed on Jim script that over WRR put > a RED qdisc, but I don't understand it. > > bests > > andres > ___ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > __ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] esfq ? or wrr ?
Hi If I have a HTB class with 128kbit, and I want to put "N" users in that class ( in order to share bandwidth fairly ) , which is better for me ? esfq (hash dst) or wrr ? I would attach esfq or wrr to HTB parent class. Also I've readed on Jim script that over WRR put a RED qdisc, but I don't understand it. bests andres ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ESFQ?
Stephen Hemminger wrote: On Tue, 11 Jan 2005 23:06:27 + Andy Furniss <[EMAIL PROTECTED]> wrote: Thomas Graf wrote: * Andy Furniss <[EMAIL PROTECTED]> 2005-01-11 15:28 diff -urN linux-2.6.10.orig/include/linux/pkt_sched.h linux-2.6.10/include/linux/pkt_sched.h @@ -136,6 +143,7 @@ __u32 limit; /* Maximal packets in queue */ unsigneddivisor;/* Hash divisor */ unsignedflows; /* Maximal number of flows */ + unsignedhash_kind; /* Hash function to use for flow identification */ }; This breaks compatibility to older iproute2 versions compiled with older header versions (not including the additional 4 octets). sch_sfq.c: if (opt->rta_len < RTA_LENGTH(sizeof(*ctl))) return -EINVAL; I did wonder if it could just come out now that iproute2 uses its own pkt_sched.h. Just to be sure I understand - it's a risk that always existed eg. before Stephen maintained iproute2, when it compiled against kernel headers. If I patched kernel and failed to compile new tc/had old tc ahead in path etc. then sfq would be broken. So if you patch make sure you build and use new tc do tc -V / check you don't have an old one in /sbin as iproute2's make install uses /usr/sbin by default. We need to maintain binary compatibility so that old command with latest kernel, and new command works with old kernel. That restricts message formats. But not source compatibility for iproute2, the iproute2 package needs to be self-contained and not depend on external (kernel) headers that may or may not be up to date. Also, older version of iproute2 compiled with current kernel headers should be supported. I would rather see all versions of iproute2 tarball's as self contained and not depend on kernel headers. Ahh - I think I see what you mean. If esfq wants to get into kernel then it has to become a completly new queue and not mess with sfq options at all. Andy. ___ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ESFQ?
On Tue, 11 Jan 2005 23:06:27 + Andy Furniss <[EMAIL PROTECTED]> wrote: > Thomas Graf wrote: > > * Andy Furniss <[EMAIL PROTECTED]> 2005-01-11 15:28 > > > >>diff -urN linux-2.6.10.orig/include/linux/pkt_sched.h > >>linux-2.6.10/include/linux/pkt_sched.h > >>@@ -136,6 +143,7 @@ > >>__u32 limit; /* Maximal packets in queue */ > >>unsigneddivisor;/* Hash divisor */ > >>unsignedflows; /* Maximal number of flows */ > >>+ unsignedhash_kind; /* Hash function to use for flow > >>identification */ > >> }; > > > > > > This breaks compatibility to older iproute2 versions > > compiled with older header versions (not including > > the additional 4 octets). sch_sfq.c: > > > > if (opt->rta_len < RTA_LENGTH(sizeof(*ctl))) > > return -EINVAL; > > I did wonder if it could just come out now that iproute2 uses its own > pkt_sched.h. > > Just to be sure I understand - it's a risk that always existed eg. > before Stephen maintained iproute2, when it compiled against kernel > headers. If I patched kernel and failed to compile new tc/had old tc > ahead in path etc. then sfq would be broken. > > So if you patch make sure you build and use new tc do tc -V / check you > don't have an old one in /sbin as iproute2's make install uses /usr/sbin > by default. > We need to maintain binary compatibility so that old command with latest kernel, and new command works with old kernel. That restricts message formats. But not source compatibility for iproute2, the iproute2 package needs to be self-contained and not depend on external (kernel) headers that may or may not be up to date. Also, older version of iproute2 compiled with current kernel headers should be supported. I would rather see all versions of iproute2 tarball's as self contained and not depend on kernel headers. ___ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ESFQ?
Thomas Graf wrote:
* Andy Furniss <[EMAIL PROTECTED]> 2005-01-11 15:28
diff -urN linux-2.6.10.orig/include/linux/pkt_sched.h
linux-2.6.10/include/linux/pkt_sched.h
@@ -136,6 +143,7 @@
__u32 limit; /* Maximal packets in queue */
unsigneddivisor;/* Hash divisor */
unsignedflows; /* Maximal number of flows */
+ unsignedhash_kind; /* Hash function to use for flow
identification */
};
This breaks compatibility to older iproute2 versions
compiled with older header versions (not including
the additional 4 octets). sch_sfq.c:
if (opt->rta_len < RTA_LENGTH(sizeof(*ctl)))
return -EINVAL;
I did wonder if it could just come out now that iproute2 uses its own
pkt_sched.h.
Just to be sure I understand - it's a risk that always existed eg.
before Stephen maintained iproute2, when it compiled against kernel
headers. If I patched kernel and failed to compile new tc/had old tc
ahead in path etc. then sfq would be broken.
So if you patch make sure you build and use new tc do tc -V / check you
don't have an old one in /sbin as iproute2's make install uses /usr/sbin
by default.
+static int esfq_change(struct Qdisc *sch, struct rtattr *opt)
+{
+ struct esfq_sched_data *q = qdisc_priv(sch);
+ struct tc_sfq_qopt *ctl = RTA_DATA(opt);
+ int old_perturb = q->perturb_period;
+
+ if (opt->rta_len < RTA_LENGTH(sizeof(*ctl)))
+ return -EINVAL;
+
+ sch_tree_lock(sch);
+ q->quantum = ctl->quantum ? : psched_mtu(sch->dev);
+ q->perturb_period = ctl->perturb_period*HZ;
+// q->hash_divisor = ctl->divisor;
+// q->tail = q->limit = q->depth = ctl->flows;
+
+ if (ctl->limit)
+ q->limit = min_t(u32, ctl->limit, q->depth);
+
+ if (ctl->hash_kind) {
+ q->hash_kind = ctl->hash_kind;
+ if (q->hash_kind != TCA_SFQ_HASH_CLASSIC)
+ q->perturb_period = 0;
+ }
+
+ // is sch_tree_lock enough to do this ?
+ while (sch->q.qlen >= q->limit-1)
+ esfq_drop(sch);
+
+ if (old_perturb)
+ del_timer(&q->perturb_timer);
+ if (q->perturb_period) {
+ q->perturb_timer.expires = jiffies + q->perturb_period;
+ add_timer(&q->perturb_timer);
+ } else {
+ q->perturbation = 0;
+ }
+ sch_tree_unlock(sch);
+ return 0;
+}
Must be changed to use tcf_exts and ematch api once those patches
are merged. I will take care of this.
I'll have a closer look later on this week.
Thanks.
Andy.
___
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ESFQ?
* Andy Furniss <[EMAIL PROTECTED]> 2005-01-11 15:28
> diff -urN linux-2.6.10.orig/include/linux/pkt_sched.h
> linux-2.6.10/include/linux/pkt_sched.h
> @@ -136,6 +143,7 @@
> __u32 limit; /* Maximal packets in queue */
> unsigneddivisor;/* Hash divisor */
> unsignedflows; /* Maximal number of flows */
> + unsignedhash_kind; /* Hash function to use for flow
> identification */
> };
This breaks compatibility to older iproute2 versions
compiled with older header versions (not including
the additional 4 octets). sch_sfq.c:
if (opt->rta_len < RTA_LENGTH(sizeof(*ctl)))
return -EINVAL;
> +static int esfq_change(struct Qdisc *sch, struct rtattr *opt)
> +{
> + struct esfq_sched_data *q = qdisc_priv(sch);
> + struct tc_sfq_qopt *ctl = RTA_DATA(opt);
> + int old_perturb = q->perturb_period;
> +
> + if (opt->rta_len < RTA_LENGTH(sizeof(*ctl)))
> + return -EINVAL;
> +
> + sch_tree_lock(sch);
> + q->quantum = ctl->quantum ? : psched_mtu(sch->dev);
> + q->perturb_period = ctl->perturb_period*HZ;
> +// q->hash_divisor = ctl->divisor;
> +// q->tail = q->limit = q->depth = ctl->flows;
> +
> + if (ctl->limit)
> + q->limit = min_t(u32, ctl->limit, q->depth);
> +
> + if (ctl->hash_kind) {
> + q->hash_kind = ctl->hash_kind;
> + if (q->hash_kind != TCA_SFQ_HASH_CLASSIC)
> + q->perturb_period = 0;
> + }
> +
> + // is sch_tree_lock enough to do this ?
> + while (sch->q.qlen >= q->limit-1)
> + esfq_drop(sch);
> +
> + if (old_perturb)
> + del_timer(&q->perturb_timer);
> + if (q->perturb_period) {
> + q->perturb_timer.expires = jiffies + q->perturb_period;
> + add_timer(&q->perturb_timer);
> + } else {
> + q->perturbation = 0;
> + }
> + sch_tree_unlock(sch);
> + return 0;
> +}
Must be changed to use tcf_exts and ematch api once those patches
are merged. I will take care of this.
I'll have a closer look later on this week.
___
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ESFQ?
Thanks - really appreciate the help!
-justin
Andy Furniss wrote:
Justin Schoeman wrote:
Woohoo - that would be great!
-justin
Andy Furniss wrote:
Justin Schoeman wrote:
Ouch... Is there any other way to do host-based fair sharing (well,
other than actually classifying each host :-( )?
I don't think it will take much to get it to work - though I haven't
tried :-) .
I'll have a look at doing a 2.6.10 in the next few days.
Well I gave it a go (first patches I've made) and they work for me
though Thomas or Stephen may notice something :-) .
Hopefully they won't be needed in the future if Thomas gets esfq in
mainline.
They are based on Alexander Clouters patches at www.digriz.org.uk. I
only used the first iproute one.
I was hampered a bit because kernel.org have turned off the diff viewer.
The remove db iproute patch is from LFS, you may not need it if you have
Berkley DB installed ( search for db_185.h ).
If you don't have it *and* you don't use arpd then use the patch, it
just removes arpd from the build.
Andy.
diff -urN iproute2-2.6.9.orig/include/linux/pkt_sched.h iproute2-2.6.9/include/linux/pkt_sched.h
--- iproute2-2.6.9.orig/include/linux/pkt_sched.h 2004-10-19 21:49:02.0 +0100
+++ iproute2-2.6.9/include/linux/pkt_sched.h 2005-01-11 11:46:45.395401296 +
@@ -126,6 +126,13 @@
/* SFQ section */
+enum
+{
+ TCA_SFQ_HASH_CLASSIC,
+ TCA_SFQ_HASH_DST,
+ TCA_SFQ_HASH_SRC,
+};
+
struct tc_sfq_qopt
{
unsigned quantum; /* Bytes per round allocated to flow */
@@ -133,6 +140,7 @@
__u32 limit; /* Maximal packets in queue */
unsigned divisor; /* Hash divisor */
unsigned flows; /* Maximal number of flows */
+ unsigned hash_kind; /* Hash function to use for flow identification */
};
/*
@@ -142,6 +150,8 @@
*
* The only reason for this is efficiency, it is possible
* to change these parameters in compile time.
+ *
+ * If you need to play with this values use esfq
*/
/* RED section */
diff -urN iproute2-2.6.9.orig/tc/Makefile iproute2-2.6.9/tc/Makefile
--- iproute2-2.6.9.orig/tc/Makefile 2004-10-19 21:49:02.0 +0100
+++ iproute2-2.6.9/tc/Makefile 2005-01-11 11:46:45.396401144 +
@@ -6,6 +6,7 @@
TCMODULES :=
TCMODULES += q_fifo.o
TCMODULES += q_sfq.o
+TCMODULES += q_esfq.o
TCMODULES += q_red.o
TCMODULES += q_prio.o
TCMODULES += q_tbf.o
diff -urN iproute2-2.6.9.orig/tc/q_esfq.c iproute2-2.6.9/tc/q_esfq.c
--- iproute2-2.6.9.orig/tc/q_esfq.c 1970-01-01 01:00:00.0 +0100
+++ iproute2-2.6.9/tc/q_esfq.c 2005-01-11 11:47:29.424707824 +
@@ -0,0 +1,168 @@
+/*
+ * q_esfq.c ESFQ.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Authors: Alexey Kuznetsov, <[EMAIL PROTECTED]>
+ *
+ * Changes: Alexander Atanasov, <[EMAIL PROTECTED]>
+ * Added depth,limit,divisor,hash_kind options.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "utils.h"
+#include "tc_util.h"
+
+static void explain(void)
+{
+ fprintf(stderr, "Usage: ... esfq [ perturb SECS ] [ quantum BYTES ] [ depth FLOWS ]\n\t[ divisor HASHBITS ] [ limit PKTS ] [ hash HASHTYPE]\n");
+ fprintf(stderr,"Where: \n");
+ fprintf(stderr,"HASHTYPE := { classic | src | dst }\n");
+}
+
+#define usage() return(-1)
+
+static int esfq_parse_opt(struct qdisc_util *qu, int argc, char **argv, struct nlmsghdr *n)
+{
+ int ok=0;
+ struct tc_sfq_qopt opt;
+
+ memset(&opt, 0, sizeof(opt));
+
+ opt.hash_kind= TCA_SFQ_HASH_CLASSIC;
+
+ while (argc > 0) {
+ if (strcmp(*argv, "quantum") == 0) {
+ NEXT_ARG();
+ if (get_size(&opt.quantum, *argv)) {
+fprintf(stderr, "Illegal \"quantum\"\n");
+return -1;
+ }
+ ok++;
+ } else if (strcmp(*argv, "perturb") == 0) {
+ NEXT_ARG();
+ if (get_integer(&opt.perturb_period, *argv, 0)) {
+fprintf(stderr, "Illegal \"perturb\"\n");
+return -1;
+ }
+ ok++;
+ } else if (strcmp(*argv, "depth") == 0) {
+ NEXT_ARG();
+ if (get_integer(&opt.flows, *argv, 0)) {
+fprintf(stderr, "Illegal \"depth\"\n");
+return -1;
+ }
+ ok++;
+ } else if (strcmp(*argv, "divisor") == 0) {
+ NEXT_ARG();
+ if (get_integer(&opt.divisor, *argv, 0)) {
+fprintf(stderr, "Illegal \"divisor\"\n");
+return -1;
+ }
+ if(opt.divisor >= 15) {
+fprintf(stderr, "Illegal \"divisor\" must be < 15\n");
+return -1;
+ }
+ opt.divisor=pow(2,opt.divisor);
+ ok++;
+ } else if (strcmp(*argv, "limit") == 0) {
+ NEXT_ARG();
+ if (get_integer(&opt.limit, *argv, 0)) {
+fprintf(stderr, "Illegal \"limit\"\n");
+return -1;
+ }
+ ok++;
+ } else if (strcmp(*argv, "hash") == 0) {
+ NEXT_ARG();
+ if(strcmp(*argv,"classic") == 0) {
+opt.hash_kind= TCA_SFQ_HASH_CLASSIC;
+
Re: [LARTC] ESFQ?
Cheers Andy, great work. Brian On 11 Jan 2005 at 15:28, Andy Furniss wrote: > Justin Schoeman wrote: > > Woohoo - that would be great! > > > > -justin > > > > Andy Furniss wrote: > > > >> Justin Schoeman wrote: > >> > >>> Ouch... Is there any other way to do host-based fair sharing > >>> (well, other than actually classifying each host :-( )? > >> > >> > >> > >> I don't think it will take much to get it to work - though I > >> haven't tried :-) . > >> > >> I'll have a look at doing a 2.6.10 in the next few days. > > Well I gave it a go (first patches I've made) and they work for me > though Thomas or Stephen may notice something :-) . > > Hopefully they won't be needed in the future if Thomas gets esfq in > mainline. > > They are based on Alexander Clouters patches at www.digriz.org.uk. I > only used the first iproute one. > > I was hampered a bit because kernel.org have turned off the diff > viewer. > > The remove db iproute patch is from LFS, you may not need it if you > have Berkley DB installed ( search for db_185.h ). > > If you don't have it *and* you don't use arpd then use the patch, it > just removes arpd from the build. > > Andy. > > > -- Brian Carrig Research Assistant Department of Computing & Networking Institute of Technology, Carlow Tel. No.: +353 59 9176314 ___ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ESFQ?
Justin Schoeman wrote:
Woohoo - that would be great!
-justin
Andy Furniss wrote:
Justin Schoeman wrote:
Ouch... Is there any other way to do host-based fair sharing (well,
other than actually classifying each host :-( )?
I don't think it will take much to get it to work - though I haven't
tried :-) .
I'll have a look at doing a 2.6.10 in the next few days.
Well I gave it a go (first patches I've made) and they work for me
though Thomas or Stephen may notice something :-) .
Hopefully they won't be needed in the future if Thomas gets esfq in
mainline.
They are based on Alexander Clouters patches at www.digriz.org.uk. I
only used the first iproute one.
I was hampered a bit because kernel.org have turned off the diff viewer.
The remove db iproute patch is from LFS, you may not need it if you have
Berkley DB installed ( search for db_185.h ).
If you don't have it *and* you don't use arpd then use the patch, it
just removes arpd from the build.
Andy.
diff -urN iproute2-2.6.9.orig/include/linux/pkt_sched.h
iproute2-2.6.9/include/linux/pkt_sched.h
--- iproute2-2.6.9.orig/include/linux/pkt_sched.h 2004-10-19
21:49:02.0 +0100
+++ iproute2-2.6.9/include/linux/pkt_sched.h2005-01-11 11:46:45.395401296
+
@@ -126,6 +126,13 @@
/* SFQ section */
+enum
+{
+ TCA_SFQ_HASH_CLASSIC,
+ TCA_SFQ_HASH_DST,
+ TCA_SFQ_HASH_SRC,
+};
+
struct tc_sfq_qopt
{
unsignedquantum;/* Bytes per round allocated to flow */
@@ -133,6 +140,7 @@
__u32 limit; /* Maximal packets in queue */
unsigneddivisor;/* Hash divisor */
unsignedflows; /* Maximal number of flows */
+ unsignedhash_kind; /* Hash function to use for flow
identification */
};
/*
@@ -142,6 +150,8 @@
*
* The only reason for this is efficiency, it is possible
* to change these parameters in compile time.
+ *
+ * If you need to play with this values use esfq
*/
/* RED section */
diff -urN iproute2-2.6.9.orig/tc/Makefile iproute2-2.6.9/tc/Makefile
--- iproute2-2.6.9.orig/tc/Makefile 2004-10-19 21:49:02.0 +0100
+++ iproute2-2.6.9/tc/Makefile 2005-01-11 11:46:45.396401144 +
@@ -6,6 +6,7 @@
TCMODULES :=
TCMODULES += q_fifo.o
TCMODULES += q_sfq.o
+TCMODULES += q_esfq.o
TCMODULES += q_red.o
TCMODULES += q_prio.o
TCMODULES += q_tbf.o
diff -urN iproute2-2.6.9.orig/tc/q_esfq.c iproute2-2.6.9/tc/q_esfq.c
--- iproute2-2.6.9.orig/tc/q_esfq.c 1970-01-01 01:00:00.0 +0100
+++ iproute2-2.6.9/tc/q_esfq.c 2005-01-11 11:47:29.424707824 +
@@ -0,0 +1,168 @@
+/*
+ * q_esfq.cESFQ.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Authors:Alexey Kuznetsov, <[EMAIL PROTECTED]>
+ *
+ * Changes:Alexander Atanasov, <[EMAIL PROTECTED]>
+ * Added depth,limit,divisor,hash_kind options.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "utils.h"
+#include "tc_util.h"
+
+static void explain(void)
+{
+ fprintf(stderr, "Usage: ... esfq [ perturb SECS ] [ quantum BYTES ] [
depth FLOWS ]\n\t[ divisor HASHBITS ] [ limit PKTS ] [ hash HASHTYPE]\n");
+ fprintf(stderr,"Where: \n");
+ fprintf(stderr,"HASHTYPE := { classic | src | dst }\n");
+}
+
+#define usage() return(-1)
+
+static int esfq_parse_opt(struct qdisc_util *qu, int argc, char **argv, struct
nlmsghdr *n)
+{
+ int ok=0;
+ struct tc_sfq_qopt opt;
+
+ memset(&opt, 0, sizeof(opt));
+
+ opt.hash_kind= TCA_SFQ_HASH_CLASSIC;
+
+ while (argc > 0) {
+ if (strcmp(*argv, "quantum") == 0) {
+ NEXT_ARG();
+ if (get_size(&opt.quantum, *argv)) {
+ fprintf(stderr, "Illegal \"quantum\"\n");
+ return -1;
+ }
+ ok++;
+ } else if (strcmp(*argv, "perturb") == 0) {
+ NEXT_ARG();
+ if (get_integer(&opt.perturb_period, *argv, 0)) {
+ fprintf(stderr, "Illegal \"perturb\"\n");
+ return -1;
+ }
+ ok++;
+ } else if (strcmp(*argv, "depth") == 0) {
+ NEXT_ARG();
+ if (get_integer(&opt.flows, *argv, 0)) {
+ fprintf(stderr, "Illegal \"depth\"\n");
+ return -1;
+ }
+ ok++;
+ } else if (strcmp(*argv, "divisor") == 0) {
+
Re: [LARTC] ESFQ?
Woohoo - that would be great! -justin Andy Furniss wrote: Justin Schoeman wrote: Ouch... Is there any other way to do host-based fair sharing (well, other than actually classifying each host :-( )? I don't think it will take much to get it to work - though I haven't tried :-) . I'll have a look at doing a 2.6.10 in the next few days. Andy. ___ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ESFQ?
Justin Schoeman wrote: Ouch... Is there any other way to do host-based fair sharing (well, other than actually classifying each host :-( )? I don't think it will take much to get it to work - though I haven't tried :-) . I'll have a look at doing a 2.6.10 in the next few days. Andy. ___ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ESFQ?
Ouch... Is there any other way to do host-based fair sharing (well, other than actually classifying each host :-( )? Thanks, -justin Jonathan Day wrote: To the best of my knowledge, ESFQ for Linux is essentially dead. There's a patchset - QNet - which does port ESFQ to the 2.6.8/2.6.9 kernels, but ESFQ is not split out, so it looks like an all-or-nothing deal. http://kem.p.lodz.pl/~peter/qnet/ I don't know if QNet is still being maintained - the last update on the page refers to October 2004 - and there's nothing to indicate how well the forward ports actually work in practice. A search using Google shows only older ESFQ versions (one for 2.6.0-test11, for example) but nothing newer. There was one posting about ESFQ to the kernel developers mailing list, but I couldn't see any follow-ups to it. Nor does it appear to be in Andrew Morton's patchset (an excellent indicator of interest level and the probability of ending up in the official kernel). Unfortunately, this seems to be fairly common in Linux QoS - too many one-man projects and too few resources too keep them going. --- Justin Schoeman <[EMAIL PROTECTED]> wrote: Hi again, I was just looking around for ESFQ sources, and I see that the main site is down, and only has kernel 2.6.4 patches. Is ESFQ maintained? If so, where can I find patches for 2.6.10? Thanks, -justin ___ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail ___ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ESFQ?
To the best of my knowledge, ESFQ for Linux is essentially dead. There's a patchset - QNet - which does port ESFQ to the 2.6.8/2.6.9 kernels, but ESFQ is not split out, so it looks like an all-or-nothing deal. http://kem.p.lodz.pl/~peter/qnet/ I don't know if QNet is still being maintained - the last update on the page refers to October 2004 - and there's nothing to indicate how well the forward ports actually work in practice. A search using Google shows only older ESFQ versions (one for 2.6.0-test11, for example) but nothing newer. There was one posting about ESFQ to the kernel developers mailing list, but I couldn't see any follow-ups to it. Nor does it appear to be in Andrew Morton's patchset (an excellent indicator of interest level and the probability of ending up in the official kernel). Unfortunately, this seems to be fairly common in Linux QoS - too many one-man projects and too few resources too keep them going. --- Justin Schoeman <[EMAIL PROTECTED]> wrote: > Hi again, > > I was just looking around for ESFQ sources, and I > see that the main site > is down, and only has kernel 2.6.4 patches. > > Is ESFQ maintained? If so, where can I find patches > for 2.6.10? > > Thanks, > -justin > ___ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: > http://lartc.org/ > __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail ___ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] ESFQ?
Hi again, I was just looking around for ESFQ sources, and I see that the main site is down, and only has kernel 2.6.4 patches. Is ESFQ maintained? If so, where can I find patches for 2.6.10? Thanks, -justin ___ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] esfq hash type
Patrick McHardy wrote: > > Marcin Sura wrote: > > >Hi > > I set up an esfq qdisc for outgoing traffic. And there is a little > > question. Does source hash type in esfq recognize NATed local ip's? > > No, but with this little hack (against esfq-patched kernel) it does. > > Regards > Patrick > > diff -urN a/net/sched/sch_esfq.c b/net/sched/sch_esfq.c > --- a/net/sched/sch_esfq.c 2004-06-05 15:45:19.0 +0200 > +++ b/net/sched/sch_esfq.c 2004-06-05 15:47:21.0 +0200 Patrick, Does this work both with and without NAT? I'd like to propose that the original sfq be entirely replaced with esfq. Except, of course, that sfq has been maintained and esfq has not. Nor are the esfq docs (at least what I can find) sufficient any more. gypsy ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] esfq hash type
Marcin Sura wrote:
Hi
I have a small lan (10.0.0.0/8) behind my linux box. I use MASQUERADE to allow
users connects to internet.
I set up an esfq qdisc for outgoing traffic. And there is a little
question. Does source hash type in esfq recognize NATed local ip's?
No, but with this little hack (against esfq-patched kernel) it does.
Regards
Patrick
diff -urN a/net/sched/sch_esfq.c b/net/sched/sch_esfq.c
--- a/net/sched/sch_esfq.c 2004-06-05 15:45:19.0 +0200
+++ b/net/sched/sch_esfq.c 2004-06-05 15:47:21.0 +0200
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -109,6 +110,18 @@
return h & (q->hash_divisor-1);
}
+static inline u32 esfq_get_source(struct sk_buff *skb)
+{
+ struct ip_conntrack *ct;
+ int dir;
+
+ if (skb->nfct == NULL)
+ return skb->nh.iph->saddr;
+ ct = (struct ip_conntrack *)skb->nfct->master;
+ dir = CTINFO2DIR(skb->nfct - ct->infos);
+ return ct->tuplehash[dir].tuple.src.ip;
+}
+
static unsigned esfq_hash(struct esfq_sched_data *q, struct sk_buff *skb)
{
u32 h, h2;
@@ -119,7 +132,7 @@
{
struct iphdr *iph = skb->nh.iph;
h = iph->daddr;
- hs = iph->saddr;
+ hs = esfq_get_source(skb);
h2 = hs^iph->protocol;
if (!(iph->frag_off&htons(IP_MF|IP_OFFSET)) &&
(iph->protocol == IPPROTO_TCP ||
[LARTC] esfq hash type
Hi I have a small lan (10.0.0.0/8) behind my linux box. I use MASQUERADE to allow users connects to internet. I set up an esfq qdisc for outgoing traffic. And there is a little question. Does source hash type in esfq recognize NATed local ip's? -- Pozdrawiam Marcin mailto:[EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] ESFQ patch problem
I applied esfq patch to kernel then I have applied iproute2-2.2.4-now-ss001007-esfq.diff to patch iproute2 (tc utility, iproute2-ss010824) source: http://www.ssi.bg/~alex/esfq/ But whenever I try to add esfq qdisc with parameter it says it donot know the qdisc i.e esfq. tc qdisc add dev eth0 parent 1:13 handle 13: esfq perturb 34 quantum 1514 depth 25 divisor 23 limit 34534 hash src Unknown qdisc "esfq", hence option "perturb" is unparsable but if I donot specify any parameters i.e tc qdisc add dev eth0 parent 1:13 handle 13: sfq perturb 3 qdisc esfq 13: [Unknown qdisc, optlen=24] is added. Is their some incompatibility between kernel and tc utility ? I am working in a customized kernel with minimum functionality (embedded applications).Is some thing missing? ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ESFQ updates
Hi I using original version. I have merget only this patch: http://linux.bkbits.net:8080/linux-2.4/[EMAIL PROTECTED]|[EMAIL PROTECTED] Jiri [EMAIL PROTECTED] wrote: Hi. On Mar 12, Corey Hickey posted here(http://mailman.ds9a.nl/pipermail/lartc/2004q1/012038.html) an updated esfq patch for kernel 2.6. Has anyone backported it to kernel 2.4 ? Original esfq patch is not being kept in sync with kernel sfq, it seems. What people have been using with esfq and kernel 2.4.25, the original 2002 esfq patch ? Rubens ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ Zkontrolovane antivirusom ClamAv Scanned by ClamAv - http://www.clamav.net Zkontrolovane antivirusom ClamAv Scanned by ClamAv - http://www.clamav.net ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] ESFQ updates
Hi. On Mar 12, Corey Hickey posted here(http://mailman.ds9a.nl/pipermail/lartc/2004q1/012038.html) an updated esfq patch for kernel 2.6. Has anyone backported it to kernel 2.4 ? Original esfq patch is not being kept in sync with kernel sfq, it seems. What people have been using with esfq and kernel 2.4.25, the original 2002 esfq patch ? Rubens ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ESFQ question
Mihai Tanasescu wrote: Hello, I've seen that esfq can do flows based on src/dest addresses. I have a small lan with private ip's. I guess that in my case esfq would only work for the download part as for the upload esfq only sees the src address = the NAT address (as I can figure from KPTD). Is there any solution for this ? (regarding esfq ..not by using iptables -j MARK and setting up different classes for everyoneand using sfq) If you use IMQ it's the same, but there is a NAT patch which lets ingress work properly - maybe it would be possible to make a patch that does the same for egress. Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] ESFQ Modification
Hi!
Some time ago I faced a problem in limiting traffic on host with
multiple uplinks. Since all the stuff worked nice seemed that there
will be no problems. But then I realized that P2P users are smart
enough to bypass limits as sfq doesn't give fair sharing in this case
(thousands of connections from one user versus few from the other).
I tried IMQ but it's instability in my configuration was painfull.
So I made something like that:
1. i use IPMARK patch for the iptables to mark all the connections
in P2P related class depending on source IP (i use SNAT),
2. modified ESFQ to create hash depending on FWMARK instead of src ip
3. and it worked. So I have uplink policy based on source ip in
snat-ed environment without using IMQ.
I'm looking for the opinions, cause I may be wrong in this.
Patch for the files below, cause it's short
diff -urN ./orig/pkt_sched.h ./patched/pkt_sched.h
--- ./orig/pkt_sched.h 2004-02-26 09:27:54.0 +0100
+++ ./patched/pkt_sched.h 2004-01-07 21:23:58.0 +0100
@@ -162,6 +162,7 @@
TCA_SFQ_HASH_CLASSIC,
TCA_SFQ_HASH_DST,
TCA_SFQ_HASH_SRC,
+ TCA_SFQ_HASH_FWMARK,
};
diff -urN ./orig/q_esfq.c ./patched/q_esfq.c
--- ./orig/q_esfq.c 2004-02-26 09:28:10.0 +0100
+++ ./patched/q_esfq.c 2004-01-07 22:08:04.0 +0100
@@ -30,7 +30,7 @@
{
fprintf(stderr, "Usage: ... esfq [ perturb SECS ] [ quantum BYTES ] [ depth
FLOWS ]\n\t[ divisor HASHBITS ] [ limit PKTS ] [ hash HASHTYPE]\n");
fprintf(stderr,"Where: \n");
- fprintf(stderr,"HASHTYPE := { classic | src | dst }\n");
+ fprintf(stderr,"HASHTYPE := { classic | src | dst | fwmark }\n");
}
#define usage() return(-1)
@@ -95,6 +95,9 @@
} else
if(strcmp(*argv,"src") == 0) {
opt.hash_kind= TCA_SFQ_HASH_SRC;
+ } else
+ if(strcmp(*argv,"fwmark") == 0) {
+ opt.hash_kind= TCA_SFQ_HASH_FWMARK;
} else {
fprintf(stderr, "Illegal \"hash\"\n");
explain();
@@ -148,6 +151,9 @@
case TCA_SFQ_HASH_SRC:
fprintf(f,"src");
break;
+ case TCA_SFQ_HASH_FWMARK:
+ fprintf(f,"fw");
+ break;
default:
fprintf(f,"Unknown");
}
diff -urN ./orig/sch_esfq.c ./patched/sch_esfq.c
--- ./orig/sch_esfq.c 2004-02-26 09:27:54.0 +0100
+++ ./patched/sch_esfq.c2004-01-07 21:39:24.0 +0100
@@ -117,6 +117,7 @@
{
u32 h, h2;
u32 hs;
+ u32 nfm;
switch (skb->protocol) {
case __constant_htons(ETH_P_IP):
@@ -124,6 +125,7 @@
struct iphdr *iph = skb->nh.iph;
h = iph->daddr;
hs = iph->saddr;
+ nfm = skb -> nfmark;
h2 = hs^iph->protocol;
if (!(iph->frag_off&htons(IP_MF|IP_OFFSET)) &&
(iph->protocol == IPPROTO_TCP ||
@@ -137,6 +139,7 @@
struct ipv6hdr *iph = skb->nh.ipv6h;
h = iph->daddr.s6_addr32[3];
hs = iph->saddr.s6_addr32[3];
+ nfm = skb->nfmark;
h2 = hs^iph->nexthdr;
if (iph->nexthdr == IPPROTO_TCP ||
iph->nexthdr == IPPROTO_UDP ||
@@ -148,6 +151,7 @@
h = (u32)(unsigned long)skb->dst;
hs = (u32)(unsigned long)skb->sk;
h2 = hs^skb->protocol;
+ nfm = skb->nfmark;
}
switch(q->hash_kind)
{
@@ -157,6 +161,8 @@
return esfq_hash_u32(q,h);
case TCA_SFQ_HASH_SRC:
return esfq_hash_u32(q,hs);
+ case TCA_SFQ_HASH_FWMARK:
+ return esfq_hash_u32(q,nfm);
default:
if (net_ratelimit())
printk(KERN_DEBUG "esfq unknown hash method, fallback to
classic\n");
--
Greetings,
Robert mailto:[EMAIL PROTECTED]
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] ESFQ question
Hello, I've seen that esfq can do flows based on src/dest addresses. I have a small lan with private ip's. I guess that in my case esfq would only work for the download part as for the upload esfq only sees the src address = the NAT address (as I can figure from KPTD). Is there any solution for this ? (regarding esfq ..not by using iptables -j MARK and setting up different classes for everyoneand using sfq) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] esfq & htb
Hi, I just upgraded to kernel 2.6.2 patched with IMQ-NAT patch & ESFQ from Jim diGriz's QoS Script and now I need to patch iproutefor esfq and the latest HTB patch. I grabbed iproute2-2.4.7-now-ss010824.tar.gz and I applied the folowinf patches: iproute2-2.2.4-now-ss001007-esfq.diff and htb3.6_tc.diff I did set the corect path in Makefile pointing to /usr/src/linux-2.6.2/include and when I do "make" I get this: make[1]: Entering directory `/work/new/iproute2/lib' gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -Werror -g -I../include-glib c -include ../include-glibc/glibc-bugs.h -I/usr/src/linux-2.6.2/include -I../include -D RESOLVE_HOSTNAMES -c -o ll_map.o ll_map.c In file included from /usr/src/linux-2.6.2/include/linux/compiler.h:16, from /usr/src/linux-2.6.2/include/asm/byteorder.h:5, from /usr/src/linux-2.6.2/include/linux/in.h:241, from ../include-glibc/netinet/in.h:7, from ll_map.c:19: /usr/src/linux-2.6.2/include/linux/compiler-gcc3.h:19:1: "__attribute_used__" redefined In file included from /usr/include/features.h:291, from ../include-glibc/glibc-bugs.h:4, from :1: /usr/include/sys/cdefs.h:192:1: this is the location of the previous definition In file included from /usr/src/linux-2.6.2/include/linux/compiler.h:16, from /usr/src/linux-2.6.2/include/asm/byteorder.h:5, from /usr/src/linux-2.6.2/include/linux/in.h:241, from ../include-glibc/netinet/in.h:7, from ll_map.c:19: /usr/src/linux-2.6.2/include/linux/compiler-gcc3.h:22:1: "__attribute_pure__" redefined In file included from /usr/include/features.h:291, from ../include-glibc/glibc-bugs.h:4, from :1: /usr/include/sys/cdefs.h:183:1: this is the location of the previous definition make[1]: *** [ll_map.o] Error 1 make[1]: Leaving directory `/work/new/iproute2/lib' make: *** [all] Error 2 My config is RH9 with gcc-3.2.2-5 and glibc-2.3.2-27.9 Any solutions in this case? Another thing: I have a squid server setup with equalize load-balancing over 3 internet links and it runs on kernel 2.4.23. I know that for the 2.4.X kernel I had to apply a patch for equalize to work at packet level and not at connection level. For kernel 2.6.2 is it included (I don;t think so...) or do I have to get another patch. If so, from where? Alex Iruc Administrator Retea LG-NET http://www.hostingcenter.ro Suport Tehnic: [EMAIL PROTECTED] Marketing: [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] esfq testing !
Hi, I'm have a linux router like this: ADSL modem-->(eth0) Linux Router (eth1)<--->LAN (6 hosts) Since I want to apply fairness to 6 hosts LAN, I have compiled kernel 2.4.20-8 with patch esfq 0.2 (and iproute2 with patch esfq too.) Next, I run folow script: #!/usr/bin TC="/sbin/tc" $TC qdisc del dev eth1 root 2> /dev/null > /dev/null $TC qdisc add dev eth1 root handle 1:0 esfq perturb 0 hash dst $TC class show dev eth1 $TC qdisc show dev eth1 $TC filter show dev eth1 And it shows me: qdisc esfq 1: quantum 1514b hash: dst Next, I make test from server to LAN hosts, and put iptraf in order to make measures. when I do: # nohup ping 192.168.1.3 -f & (a LAN HOST) # nohup ping 192.168.1.6 -f & (other LAN HOST) iptraf shows me equal bandwidth to that hosts. but if I repeat pings for one of that hosts: # nohup ping 192.168.1.6 -f & (other LAN HOST) # nohup ping 192.168.1.6 -f & (other LAN HOST) # nohup ping 192.168.1.6 -f & (other LAN HOST) iptraf shows me that 192.168.1.6 get more bandwidth that 192.168.1.3 Then seems ESFQ behaviour is like SFQ... what is wrong I have ESFQ compiled like module. Also I've tried put ESFQ inside a HTB class but ESFQ behaviour is equal like above example. Where is the problem ? Thank you !!! Mac ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] esfq
hi, I want to try esfq in order to make a load balance in my linux router, (both, lan side and interent side) I want that all hosts of my lan haves the same bandwidth avaible. Since linux router are connected to an ISP which privide a variable bandwidth, I think that can't use HTB. Also, in this situation, how can I do to priorize some LAN hosts from others ? Thanks you very much in advance. Andres. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] ESFQ - optimal parameters?
Hi! Have anyone experimented with ESFQ yet? I'd like to know what the optimal depth/divisor/perturb settings are for X kilobits/per/second. For example, once could calculate the optimal limit parameter (bitrate (bps) * latency / (mtu * 1000)), but what should depth/divisor be? Also, what is the optimal perturb value in general for SFQ / ESFQ? -- Regards Abraham There are times when truth is stranger than fiction and lunch time is one of them. ___ Abraham vd Merwe [ZR1BBQ] - Frogfoot Networks P.O. Box 3472, Matieland, Stellenbosch, 7602 Cell: +27 82 565 4451 Http: http://www.frogfoot.net/ Email: [EMAIL PROTECTED] msg03875/pgp0.pgp Description: PGP signature
Re: [LARTC] ESFQ patch not working with kernel 2.4.20
Hi, had also some errors, but the .config-option was available and the module compiled fine. i decided to ignore the errors and the module works perfectly. but perhaps someone can fix these errors ? greetings tobias Jesper Lund wrote: Hi, I have tried to patch a 2.4.20 kernel source with esfq 1.0a. But i get som patch errors. The patch do not apply clean. Will it maybe be available for the 2.4.20 kernel soon ? Regards, Jesper ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] ESFQ patch not working with kernel 2.4.20
Hi, I have tried to patch a 2.4.20 kernel source with esfq 1.0a. But i get som patch errors. The patch do not apply clean. Will it maybe be available for the 2.4.20 kernel soon ? Regards, Jesper -- Søger nyt job. Se evt. mere info på www.ballbreaker.dk ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] ESFQ note
I finally got the problem solved. Only I want is to notice: Beware of setting perturb too small, otherwise you'll got sinusoidal result of two traffics generated by two ip's but one ip downloading with many more threads. Until esfq builds the right hash table, the ip with more threads will get more bandwidth. Esfq will have practically no time to make that streams equivalent because in 10 seconds it must create a new table and everything repeats. I've got LAN with no more than 64 ip's so I could possibly set hash table not to rebuild at all so I set perturb to 10 minutes (600) and I'm perfectly satisfied ;-) Thank's to Stef Coene for his tests with CBQ !!! Vladimir Trebicky P.S.: The only remaining problem is that I have 486 with psched JIFFIES so the QoS doesn't shape much high bandwidth... :-( ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ESFQ
On Saturday 28 September 2002 12:01, Vladimír Třebický wrote: > Hi, > > I have little problem with ESFQ. I set root qdisc cbq on eth1 (which is on > LAN side of network), then 1:1 cbq class with exact bandwidth and its two > child - cbq 1:10 and cbq 1:20 with 1:1's bandwidth divided. I also set two > ESFQ perturb 10 hash dst on those two classes. But when someone starts to > download with 100 threads, he has much more bandwith than someone with only > one. I understand that this is exactly what esfq should solve, so I think > that somewhere on my side is mistake :-( This is my configuration: > > tc qdisc add dev eth0 root handle 1: cbq bandwidth 10Mbit avpkt 1000 cell 8 > > tc class add dev eth0 parent 1: classid 1:1 cbq bandwidth 10Mbit rate 256 > Kbit weight 2.56 Kbit prio 1 allot 1514 cell 8 maxburst 20 avpkt 1000 > isolated > > tc class add dev eth0 parent 1:1 classid 1:10 cbq bandwidth 10Mbit rate 32 > Kbit weight 3.2 Kbit prio 1 allot 1514 cell 8 maxburst 18 avpkt 100 > isolated tc class add dev eth0 parent 1:1 classid 1:20 cbq bandwidth 10Mbit > rate 224 Kbit weight 2.24 Kbit prio 2 allot 1514 cell 8 maxburst 2 avpkt > 1500 bounded > > tc qdisc add dev eth0 parent 1:10 handle 10: esfq perturb 10 hash dst > tc qdisc add dev eth0 parent 1:20 handle 20: esfq perturb 10 hash dst > > iptables -t mangle -A PREROUTING -m length --length 0:500 -j MARK > --set-mark 3 > iptables -t mangle -A PREROUTING -m length --length ! 0:500 -j > MARK --set-mark 4 > > tc filter add dev eth0 parent 1: protocol ip handle 3 fw flowid 1:10 > tc filter add dev eth0 parent 1: protocol ip handle 4 fw flowid 1:20 > > Thank you very much for answer, You have to make class 1:1 bounded so it can not get more bandwidth than it's rate. And remove all isolated parameters. They are not working. In fact, if you add a isolated parameter to class 1:10 and 1:20 then these class will get more bandwidth then the parent allows even if the parent is bounded. I think it's a bug in cbq (more info on http://www.docum.org/stef.coene/qos/tests/cbq/classes.html). tc qdisc add dev eth0 root handle 1: cbq bandwidth 10Mbit avpkt 1000 cell 8 tc class add dev eth0 parent 1: classid 1:1 cbq bandwidth 10Mbit rate 256 Kbit weight 2.56 Kbit prio 1 allot 1514 cell 8 maxburst 20 avpkt 1000 bounded tc class add dev eth0 parent 1:1 classid 1:10 cbq bandwidth 10Mbit rate 32 Kbit weight 3.2 Kbit prio 1 allot 1514 cell 8 maxburst 18 avpkt 100 tc class add dev eth0 parent 1:1 classid 1:20 cbq bandwidth 10Mbit rate 224 Kbit weight 2.24 Kbit prio 2 allot 1514 cell 8 maxburst 2 avpkt 1500 Stef -- [EMAIL PROTECTED] "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] ESFQ
Hi, I have little problem with ESFQ. I set root qdisc cbq on eth1 (which is on LAN side of network), then 1:1 cbq class with exact bandwidth and its two child - cbq 1:10 and cbq 1:20 with 1:1's bandwidth divided. I also set two ESFQ perturb 10 hash dst on those two classes. But when someone starts to download with 100 threads, he has much more bandwith than someone with only one. I understand that this is exactly what esfq should solve, so I think that somewhere on my side is mistake :-( This is my configuration: tc qdisc add dev eth0 root handle 1: cbq bandwidth 10Mbit avpkt 1000 cell 8 tc class add dev eth0 parent 1: classid 1:1 cbq bandwidth 10Mbit rate 256 Kbit weight 2.56 Kbit prio 1 allot 1514 cell 8 maxburst 20 avpkt 1000 isolated tc class add dev eth0 parent 1:1 classid 1:10 cbq bandwidth 10Mbit rate 32 Kbit weight 3.2 Kbit prio 1 allot 1514 cell 8 maxburst 18 avpkt 100 isolated tc class add dev eth0 parent 1:1 classid 1:20 cbq bandwidth 10Mbit rate 224 Kbit weight 2.24 Kbit prio 2 allot 1514 cell 8 maxburst 2 avpkt 1500 bounded tc qdisc add dev eth0 parent 1:10 handle 10: esfq perturb 10 hash dst tc qdisc add dev eth0 parent 1:20 handle 20: esfq perturb 10 hash dst iptables -t mangle -A PREROUTING -m length --length 0:500 -j MARK --set-mark 3 iptables -t mangle -A PREROUTING -m length --length ! 0:500 -j MARK --set-mark 4 tc filter add dev eth0 parent 1: protocol ip handle 3 fw flowid 1:10 tc filter add dev eth0 parent 1: protocol ip handle 4 fw flowid 1:20 Thank you very much for answer, Vladimir Trebicky ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] ESFQ debugging
Is there any way to see the whole hash table of esfq to debug wheter the chosen hash table type is working correctly? This is my situation: ### ROOT tc qdisc add dev eth1 root handle 1: cbq bandwidth 10Mbit avpkt 1000 cell 8 ### CLASS PARENT tc class add dev eth1 parent 1: classid 1:1 cbq bandwidth 10Mbit \ rate 2Mbit weight 200Kbit prio 1 allot 1514 cell 8 maxburst 20 avpkt 1000 \ isolated ### CLASS PRIORITIES tc class add dev eth1 parent 1:1 classid 1:10 cbq bandwidth 10Mbit \ rate 200Kbit weigth 20Kbit prio 1 allot 1514 cell 8 maxburst 10 avpkt 100 \ isolated tc class add dev eth1 parent 1:1 classid 1:20 cbq bandwidth 10Mbit \ rate 1800Kbit weigth 180Kbit prio 2 allot 1514 cell 8 maxburst 10 avpkt 1500 \ bounded ### SFQ tc qdisc add dev eth1 parent 1:10 handle 10: esfq perturb 10 hash dst tc qdisc add dev eth1 parent 1:20 handle 20: esfq perturb 10 hash dst Plus some iptables -t mangle -A OUTPUT filters that divide traffic to 0:500 (marking as 3 and flowing to 1:10) and 500:1500 (marking as 4 and flowing to 1:20) I have another 2 linux stations. On the first (A) a ran 2 scp's and on the second (B) only 1 scp. The result isn't so definite. The scp on B ended first but in that time the first scp on A had 80% and the second somthing about 70%. In my opinion it should be something like A-100%, B1-50%, B2-50%. Any ideas? ;-) Thank you for any hint :-) -- Vladimir Trebicky ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] esfq test !!
Hi Alex !! I use esfq with src ip hash type in htb for www and ftp traffic. All working fine !! src ip hash type work almost such as WRR - if user open many connections esfq give to all his connections same priority such as user with little number of connections, yes !! I use esfq with many other patches, all work and compile fine ! list of patches : from patch-o-matic (iptables-1.2.7-20020527) arptables,netfilter-arp,REJECT-dont_fragment,ulog-module-unload, 0-newnat13,conntrack,dscp,DCSP,ownercmd,pkttype,iplimit,ipv4options, mport,NETMAP,nth,psd,quota,random,realm,SAME,time,TTL,CONNMARK,h323-conntrack-nat, helper,IMQ,pptp-conntrack-nat,recent,string,tcp-window-tracking also htb-3.6,IMQ , patch for pfifo_fast from Patrick McHardy and esfq of course ! Now I start test it (for a long time) at our internet gw with 64kbit DSL and 1,5 mbit DVB (one direction) Thanks for great work Alex !! I have fun !! :) --- mailto:[EMAIL PROTECTED] BR Alexey Talikov FORTEK --- ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
