* Re: [Linux Diffserv] GRED queueing discipline and the file sch_gred.c [not found] <20050605221106.GB15391@postel.suug.ch> @ 2005-06-06 10:38 ` rahul hari 2005-06-06 11:39 ` Thomas Graf 2005-06-06 11:45 ` jamal 0 siblings, 2 replies; 6+ messages in thread From: rahul hari @ 2005-06-06 10:38 UTC (permalink / raw) To: tgraf; +Cc: diffserv-general, netdev Dear Thomas, Thanks for the reply. Actually in my experiment, I am implementing 2 queues, in one of the queues, I use the prio scheme of tc and in another I define 3 virtual queues, out of which I want to provide absolute priority to one of the queue over the others (ie, if there is any packet in this queue, it should be dispatched immediately regardless of whatever happens to the other two virtual queues). For the other two virtual queues, I want to apply individual REDs (with different parameters but the average queue length should be equal to the total qave of these two virtual queues) on each but the dequeuing priority should be equal (the dequeuing takes place alternately). Can the current implementations somehow help me with this , or I would have to design this from scratch. Regards, Rahul ------- "The fear you let build up in your mind is worse than the situation that actually exists" taken from "who moved my cheese" ----------------------------------------------------------------------------- Rahul Hari Senior Undergraduate Student, Department of CSE, ITBHU, Varanasi. Ph: +91-9845347020 ----------------------------------------------------------------------------- _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Linux Diffserv] GRED queueing discipline and the file sch_gred.c 2005-06-06 10:38 ` [Linux Diffserv] GRED queueing discipline and the file sch_gred.c rahul hari @ 2005-06-06 11:39 ` Thomas Graf 2005-06-06 11:54 ` jamal 2005-06-06 11:45 ` jamal 1 sibling, 1 reply; 6+ messages in thread From: Thomas Graf @ 2005-06-06 11:39 UTC (permalink / raw) To: rahul hari; +Cc: diffserv-general, netdev Rahul, * rahul hari <BAY24-F263AE581155F279A048AE6C5FB0@phx.gbl> 2005-06-06 16:08 > Thanks for the reply. Actually in my experiment, I am implementing 2 > queues, in one of the queues, I use the prio scheme of tc and in another I > define 3 virtual queues, out of which I want to provide absolute priority > to one of the queue over the others (ie, if there is any packet in this > queue, it should be dispatched immediately regardless of whatever happens > to the other two virtual queues). Use a prio qdisc with RED leaf qdiscs. RED and GREDs purpose is to calculate a marking probability and not to provide any prioritizing schemes. RIO mode is a small exception from this but the used priority only describes the weight of the VQ and has no influence on the actual queue position later on. > For the other two virtual queues, I want to apply individual REDs (with > different parameters but the average queue length should be equal to the > total qave of these two virtual queues) on each but the dequeuing priority > should be equal (the dequeuing takes place alternately). Use a GRED qdisc, give both VQs the same prio (so they go into equalize mode) and enable RIO mode. The VQ you select as default will be used to store qavg and the idle time. CBQ cbq:queue_1 cbq:queue_2 | | prio GRED (rio mode) | | | | | RED_1 RED_2 RED_3 VQ1(prio=1) VQ2(prio=1) You did not talk about how to separate the two initial queues so I assumed CBQ but it doesn't really matter as long its a classful qdisc. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Linux Diffserv] GRED queueing discipline and the file sch_gred.c 2005-06-06 11:39 ` Thomas Graf @ 2005-06-06 11:54 ` jamal 2005-06-06 12:15 ` Thomas Graf 0 siblings, 1 reply; 6+ messages in thread From: jamal @ 2005-06-06 11:54 UTC (permalink / raw) To: Thomas Graf; +Cc: rahul hari, diffserv-general, netdev On Mon, 2005-06-06 at 13:39 +0200, Thomas Graf wrote: > Use a prio qdisc with RED leaf qdiscs. RED and GREDs purpose is to > calculate a marking probability and not to provide any prioritizing > schemes. Prioritization is still implicitly provided if you vary the queue lengths or the drop probabilities. For example, if you set everything to be exactly the same, and varied only the drop probability - the VQ with the highest drop probability will be less important (i.e relatively more of its packets will be dropped; recall: the drop decision is made before the packet is queued). cheers, jamal ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Linux Diffserv] GRED queueing discipline and the file sch_gred.c 2005-06-06 11:54 ` jamal @ 2005-06-06 12:15 ` Thomas Graf 2005-06-06 19:12 ` rahul hari 0 siblings, 1 reply; 6+ messages in thread From: Thomas Graf @ 2005-06-06 12:15 UTC (permalink / raw) To: jamal; +Cc: rahul hari, diffserv-general, netdev * jamal <1118058859.6266.126.camel@localhost.localdomain> 2005-06-06 07:54 > On Mon, 2005-06-06 at 13:39 +0200, Thomas Graf wrote: > > > Use a prio qdisc with RED leaf qdiscs. RED and GREDs purpose is to > > calculate a marking probability and not to provide any prioritizing > > schemes. > > Prioritization is still implicitly provided if you vary the queue > lengths or the drop probabilities. > For example, if you set everything to be exactly the same, and varied > only the drop probability - the VQ with the highest drop probability > will be less important (i.e relatively more of its packets will be > dropped; recall: the drop decision is made before the packet is queued). Absolutely, what I meant is that GRED does not take influence on the actual ordering of packets not dropped. The priority together with the qavg parameters and the thresholds only have influence on the probability a packet gets marked/dropped, sure this is prioritization as well but Rahul wanted to have one VQ strave out another VQ completely. My point is that this is not possible with GRED. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Linux Diffserv] GRED queueing discipline and the file sch_gred.c 2005-06-06 12:15 ` Thomas Graf @ 2005-06-06 19:12 ` rahul hari 0 siblings, 0 replies; 6+ messages in thread From: rahul hari @ 2005-06-06 19:12 UTC (permalink / raw) To: tgraf, hadi; +Cc: diffserv-general, netdev Thanks for all the suggestions Jamal and Thomas. >From what you people have been suggesting, i feel that i should be giving a detailed explaination of the problem I am currently working on. I have divided all the traffic on a network into 5 categories : Real time video (UDP1),Real time audio (UDP2), TCP not requiring any QoS (TCP1), TCP requiring QoS but with the size of the entire transaction very low(TCP2), and TCP requiring QoS with the size of the transaction in several MBs (TCP3). Now I am putting UDP1 and TCP1 in one particular queue (say q1) and giving priority to UDP1 (for dequeuing not caring if TCP1 is getting starved). I am putting UDP2 ,TCP2 and TCP3 in a different queue (thus keeping the average queue length almost constant) (say q2)and applying RED on each of TCP2 and TCP3 (the application of the two REDs being independent of each other). Here also I am providing priority to UDP2 (without caring if TCP2 or TCP3 is getting starved ). To schedule between q1 and q2, I am using WRR and to schedule between UDP1 and TCP1, I am using prio. For implementing q2, I am currently putting UDP2,TCP2 and TCP3 in 3 different virtual queues and applying GRED with grio. I am providing UDP2 the highest priority and providing TCP2 and TCP3 equal priorities. To ensure that RED does not apply on the UDP2, I have set Tmax=Tmin so that Pbmax=1. But the results I am getting with this configuration do not match with the results that I have got from the simulations. So I want to implement this stuff such that the UDP2 gets highest priority among the three, is not included while calculating the total average queue length and the qave used for the application of REDs on TCP2 and TCP3 should be equal to the qave of tcp2+ qave of tcp3. To schedule between TCP2 and TCP3, I want to use WRR or something that gives equal priority and prevents the starvation of any of these. PS: please send any further replies to rahul.hari@cse06.itbhu.org instead of this account Regards, Rahul ------- "The fear you let build up in your mind is worse than the situation that actually exists" taken from "who moved my cheese" ----------------------------------------------------------------------------- Rahul Hari Senior Undergraduate Student, Department of CSE, ITBHU, Varanasi. Ph: +91-9845347020 ----------------------------------------------------------------------------- > >* jamal <1118058859.6266.126.camel@localhost.localdomain> 2005-06-06 07:54 > > On Mon, 2005-06-06 at 13:39 +0200, Thomas Graf wrote: > > > > > Use a prio qdisc with RED leaf qdiscs. RED and GREDs purpose is to > > > calculate a marking probability and not to provide any prioritizing > > > schemes. > > > > Prioritization is still implicitly provided if you vary the queue > > lengths or the drop probabilities. > > For example, if you set everything to be exactly the same, and varied > > only the drop probability - the VQ with the highest drop probability > > will be less important (i.e relatively more of its packets will be > > dropped; recall: the drop decision is made before the packet is queued). > >Absolutely, what I meant is that GRED does not take influence on the >actual ordering of packets not dropped. The priority together with >the qavg parameters and the thresholds only have influence on the >probability a packet gets marked/dropped, sure this is prioritization >as well but Rahul wanted to have one VQ strave out another VQ >completely. My point is that this is not possible with GRED. _________________________________________________________________ Think Rani is the best? http://server1.msn.co.in/sp05/iifa/ Make sure she wins the award. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Linux Diffserv] GRED queueing discipline and the file sch_gred.c 2005-06-06 10:38 ` [Linux Diffserv] GRED queueing discipline and the file sch_gred.c rahul hari 2005-06-06 11:39 ` Thomas Graf @ 2005-06-06 11:45 ` jamal 1 sibling, 0 replies; 6+ messages in thread From: jamal @ 2005-06-06 11:45 UTC (permalink / raw) To: rahul hari; +Cc: tgraf, diffserv-general, netdev On Mon, 2005-06-06 at 16:08 +0530, rahul hari wrote: > Dear Thomas, > Thanks for the reply. Actually in my experiment, I am implementing 2 queues, > in one of the queues, I use the prio scheme of tc and in another I define 3 > virtual queues, out of which I want to provide absolute priority to one of > the queue over the others (ie, if there is any packet in this queue, it > should be dispatched immediately regardless of whatever happens to the other > two virtual queues). > For the other two virtual queues, I want to apply individual REDs (with > different parameters but the average queue length should be equal to the > total qave of these two virtual queues) on each but the dequeuing priority > should be equal (the dequeuing takes place alternately). > Can the current implementations somehow help me with this , or I would have > to design this from scratch. > It is not clear what your requirements are. You are stating what your solution is ;-> Assuming that you require to have the first queue to be of the utmost priority followed by the first red queue as being important and then the last two, then you need a prio qdisc with three bands: +---- pfifo | +---- RED | +---- GRED The pfifo will starved the lower 2. The RED will starve the GRED if it can and GRED virtual queues will need to be set in (CISCO) WRED mode i.e select GRIO but give them equal priority. Make sure those two VQs have exactly the same drop priorities and queue parameters. cheers, jamal ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-06-06 19:12 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20050605221106.GB15391@postel.suug.ch>
2005-06-06 10:38 ` [Linux Diffserv] GRED queueing discipline and the file sch_gred.c rahul hari
2005-06-06 11:39 ` Thomas Graf
2005-06-06 11:54 ` jamal
2005-06-06 12:15 ` Thomas Graf
2005-06-06 19:12 ` rahul hari
2005-06-06 11:45 ` jamal
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).