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
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 <gregoriandres@yahoo.com.ar> 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
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
[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.000000000 +0200
+++ sch_esfq.c 2004-01-07 21:39:24.000000000 +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.000000000 +0200
+++ pkt_sched.h 2005-10-15 09:48:31.000000000 +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.old 2005-10-15 09:57:08.000000000 +0200
+++ q_esfq.c 2005-10-15 09:51:36.000000000 +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
-> 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 <gregoriandres@yahoo.com.ar> 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
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. > > -Corey1) 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