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
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_offhtons(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 ?
- 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
[LARTC] FW: Some queueing disciplines that I wrote.
Dear LATRC and devotees, I have developed some Linux queueing disciplines. I developed them for my masters project. You are free to use or distribute my work. Here is the abstract from my dissertation:- This is a project to implement a Mice and Elephants queuing discipline on Linux. My project has three aims. The first aim was to produce a prototype Mice and Elephants router for the purpose of further evaluation of the Mice and Elephants strategy. The second aim was to make a contribution to Linux by making my implementation as code that would be both fit for distribution with Linux and useful in a small business or domestic setting. The third aim was to explore and document a method of creating Linux queuing disciplines. The rest of my dissertation, manual pages on my queuing disciplines, my own HOWTO on how to write queueing disciplines, manual pages on the kernal interface for queuing disciplines, and the tarball sourcode are all avaiable from:- http://www.sci.usq.edu.au/staff/braithwa/MastProj/index.html Please read the HOWTO for instructions on how to build and install. Please direct questions about this to [EMAIL PROTECTED] Apart from Mice and Elephants queueing disciplines, an ARED queueing discipline is there also. Yours sincerely, Stephen Braithwaite P.S. :- I would like to sell (not really - of course its all free) you the concept of mice and elephants. So here is some cut and paste from my master's dissertation:- A Mice and Elephants strategy (also called Shortest Job First) is one which favours the short flows over long flows. In a mice and elephants strategy the short flows or the packets from them are called mice, and the long flows or the packets from them are called elephants. It involves identifying flows and associating packet with their flows in order to be able to treat long flows different to short flows. One way to favor the mice is to give the mice priority when dequeueing. Another is to avoid dropping mouse packets by dropping elephant packets before the queue is full. Proponents of Mice and Elephants queuing strategies argue that equal throughput for each flow or host (sometimes called Processor Sharing or Fair Queueing) is the wrong goal. Mice and Elephants strategy response times are significantly better than those obtained using Fair Queuing. Shortest Remaining Processing Time (SRPT) has been shown to give better results than Processor Sharing for a range of measures including average task turnover time [36]. [36] uses mean task turnover time divided by job length as a measure of starva- tion, and shows both analytically and by simulation that no class of jobs are worse off when the the job sizes are heavy tailed (as they are in internet traffic). In reality, SRPT would be difficult in a queuing discipline, because we dont know the length of each job, we only know the size of a job so far. But Shortest Job First (SJF) has been shown to be a sufficiently good approximation to SRPT, to enjoy the same benefits over Processor Sharing that SRPT does. [49] shows that shortest job first gives near optimal response time regardless of which group of flows we care to observe. For example, Shortest Job First gives as good a result to medium length jobs than if we were to give them absolute priority. Simulation of an implementation of Shortest Job First is described in [13], with results that show significant gains over other strategies Two cases of congested queues fed by Poisson Pareto Burst Proccesses were math- ematically modelled. [14] One had a Pareto distribution shape parameter of 1.4 (heavy tails) and the other had a Pareto distribution shape parameter of 1.2 (very heavy tails). Both cases were modelled with a Mice and Elephants strategy and without. The benefit from the Mice and Elephants strategy was assessed by calculating the extra capacity needed when the Mice and Elephant strategy was not used in order that at most 5% of flows are delayed by more than 20%. In the heavy tails case, 16% more capacity was required. In the very heavy tails case 40% more capacity was required. The modelling showed that the benefit of a mice and elephants strategy would be quite significant. Long flows consitute a small minority, but make up the vast majority of traffic. About 20% of the flows have more than 10 packets but these flows carry 85% of the total traffic. [60] [24] During periods of traffic congestion the long flows account for an even greater percentage of the traffic than they do if we take overall traffic mea- surments. In [15] an example was given where the short flows accounted for 89% of the traffic flow and the long flows accounted for the other 11% of the traffic flow over- all. During periods of high congestion, the long flows accounted for a disproportionate amount of the traffic flow - perhaps 88%. It stands to reason that interactive short flows are delay sensitive as far as
Re: [LARTC] FW: Some queueing disciplines that I wrote.
Stephen, this sounds interesting. One question : did you address the 'arms race' with file sharing application developers ? What I mean is that giving preference to short flows seems like a fine idea until footorrent or whatever comes along that has the strategy of opening zillions of short-lived connections to a large number of servers. Now all the flows are short and there are no long flows to give lower priority to. Thoughts ? (I did read quickly through your thesis but couldn't see anything on this. Apologies if I missed it). ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] FW: Some queueing disciplines that I wrote.
David, I am a newbie to the list - and dont know how to to reply on the correct thread - but here goes:- Your objection is spot on. Bit torrent seems to present a real challenge. The definition of a flow need not be the TCP definition of a flow. I am not sure if it will help, but any the queuing discipline and ingress que filter are able to work with any combination of protocol, source port number, source ip, dest port, dest ip as the definition of a flow. This may or may not help. -Original Message- From: David Boreham [mailto:[EMAIL PROTECTED] Sent: Sun 10/16/2005 12:14 AM To: Stephen Braithwaite Cc: lartc@mailman.ds9a.nl Subject: Re: [LARTC] FW: Some queueing disciplines that I wrote. Stephen, this sounds interesting. One question : did you address the 'arms race' with file sharing application developers ? What I mean is that giving preference to short flows seems like a fine idea until footorrent or whatever comes along that has the strategy of opening zillions of short-lived connections to a large number of servers. Now all the flows are short and there are no long flows to give lower priority to. Thoughts ? (I did read quickly through your thesis but couldn't see anything on this. Apologies if I missed it). ___ 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
[LARTC] (no subject)
Dear all, Please someone help me regarding how to merge 2 internet link connection. I need to double the speed into my LAN. Is it possible to do that? Thx. KOMUNIKA SYSTEM Internet Solution Provider www.komunikasys.com ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] general shaping rules
Hi, i dont fully understand this sentence, could someone be so kind to expleain me it? Any router performing a shaping function should be the bottleneck on the link, and should be shaping slightly below the maximum available link bandwidth. This prevents queues from forming in other routers, affording maximum control of packet latency/deferral to the shaping device. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] general shaping rules
On Saturday, 15 October 2005, at 20:29:20 +0200, Jorge Sanchez wrote: Any router performing a shaping function should be the bottleneck on the link, and should be shaping slightly below the maximum available link bandwidth. This prevents queues from forming in other routers, affording maximum control of packet latency/deferral to the shaping device. In the Internet, traffic flows through a number of router between source and destination, routers you can not control. In the router closest to your network (if using ADSL, the local telephone witching central with DSLAM adapters) sometimes the ISP or telco applies buffering to each subscriber. That is, to get tranfer rates up it is very easy to allocate and indeterminate (but usually large) buffer for incoming traffic. This way, when you download at full speed you get, well, full speed, but the telco is getting more data at a rate greater than you can, so it buffers traffic in excess. So, if the sending box somewhat slows down (network congestion), your telco still has data to send and keep your line 100% full. So statistics show you get a fantastic service bandwitdh wise, but not so good with respect to latency. The only way to prevent those buffer to even start filling is shaping traffic to/from your network some Kbps bellow your nominal maximun transfer rate. You have to be the bottelneck to be able to control bandwidth allocation and keep latency to a minumun. Hope I made an understandable explanation. Greetings, -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.14-rc3-git7) signature.asc Description: Digital signature ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] FW: Some queueing disciplines that I wrote.
I have an objection too: VoIP (Voice over IP), video and audio streaming are elephants. They are big flows, yet people don't like movies played as picture slideshows and interrupted audio or phone calls. End of objection. Trying to build a solution: Making the hipothesis. I think intrractive traffic shoud be defined and recognized not by it's packet size nor by duration of the connection nor by ports it comes or goes. We do not have a computerized definition of interactive traffic, so we cannot separate it from bulk traffic. We know that interractive traffic = traffic that should have such priority that the user can interract with the network without being annoyed by network latency. Bulk traffic = traffic that the user don't care if is delayed for a few seconds, but has to take place and finnish in resonable time. The conclusions: 1. Now that the definitions are given, how can we sepparate the two, living no chance for programmers to cheat the algorithm? Or maybe we can trust them and ask them for help and set for interractive applications' traffic some bits that the routers can recognize and build some queues accordingly. 2. How many classes do we need and what applications could be into each of them? Waiting for some ideas... __ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] FW: Some queueing disciplines that I wrote.
I have an objection too: VoIP (Voice over IP), video and audio streaming are elephants. They are big flows, yet people don't like movies played as picture slideshows and interrupted audio or phone calls. End of objection. - Panca Sorin Panca Sorin is correct. Video and audio streaming would suffer if classified as elephants. Fortunately they have a different type of service and are likely to be associated with certain port numbers. Linux is flexible and allows you to separate these streams using something like . If you used video or audio streaming you would separate these out, probably using the u32 classifier. Because these are fixed rate, and because they require their fixed rate, these streams need to be given absolute priority. So the prio classful queuing discipline would be a suitable contianer. Within the prio classful queuing discipline, the fixed rate flows should be channeled into a simple drop tail, while the remainder could be channeled into a mice and elephants queueing discipline such as meredt. winmail.dat___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] regarding lartc howto
Hi, Is the following link is current, if not, any pointers will be appreciated. http://lartc.org/howto/ regards, /virendra ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] regarding lartc howto
Sorry about the typo, I meant to ask, is the following still current, if not, any pointers will be appreciated. regards, /virendra noc ops wrote: Hi, Is the following link is current, if not, any pointers will be appreciated. http://lartc.org/howto/ regards, /virendra ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
