We have been able to fix our code. It can compile now. Nevertheless, I would be more than thankful if you could give me your opinion on our problem with LinkUnqueue element inside version 1.8.0. Since there is no such a problem, someone has to know where the bug was?
Anyone? Thanks! On Mon, Jun 27, 2011 at 1:29 PM, Eddie Kohler <koh...@cs.ucla.edu> wrote: > Milos, > > Please be specific about what compilation problems you are seeing and we > will fix them. It is almost always better to use newer code. > > Eddie > > > > On 06/27/2011 12:37 AM, milos rovcanin wrote: > >> Hello, >> >> The latest GIT version of Click works fine and the problem we had seems to >> be >> solved, but there are some other elements that won't compile under the it. >> It >> turns out that the latest GIT provides more problems than solutions. Could >> anyone , please, take a look at the simple configuration that I sent in my >> last mail? I have explained the behavior of it as well. >> >> Thank you in advance!!! >> >> On Fri, Jun 24, 2011 at 10:08 AM, milos rovcanin <ro1208...@gmail.com >> <mailto:ro1208...@gmail.com>> wrote: >> >> Before we downloaded GIT version: >> >> After doing some more tests, I found out that when no drops occur (eg >> 500 >> bytes packets,shaping on 10Mbps, and UDP load of 20Mbps), there are >> only >> 10Mbps packets that enter Click (took a dump just after the >> FromDevice)??!!! >> >> When drops do occur (e.g. 1000bytes packet, shaping on 10Mbps and UDP >> load of 20Mbps), 20Mbps packets enter Click, are sent to the queue and >> off >> course are dropped there because the LinkUnqueue pulls at the shaping >> rate. This is behaviour that we expect. >> >> Now when I use 500 bytes packets but shape it on 5Mbps and UDP load of >> 20Mbps, packets are dropped! So, I then get expected behaviour: 20mbps >> packets enter click, sent to the queue and pulled at 5mbps by the >> linkunqueue shaper. So there is some correlation between packet size >> and >> shaping rate. >> >> When it goes wrong, it seems like the Linkunqueue element pulls all the >> way to the FromDevice, even when there is a queue element in between, >> and >> FromDevice is actually a push element.. >> >> On Fri, Jun 24, 2011 at 10:04 AM, milos rovcanin <ro1208...@gmail.com >> <mailto:ro1208...@gmail.com>> wrote: >> >> My colleagues and I have just finished testing our configuration >> with >> the latest GIT version and it works fine!!! >> >> >> >> On Fri, Jun 24, 2011 at 4:18 AM, Eddie Kohler <koh...@cs.ucla.edu >> <mailto:koh...@cs.ucla.edu>> wrote: >> >> Please cc: your replies to the list. >> >> >> On 06/23/2011 04:22 PM, milos rovcanin wrote: >> >> Hello, >> I am not sure that you have understood me right: I am using >> Jperf 2.0 to >> generate UDP/TCP traffic and I am trying to send TWO flows >> at >> the same time, >> from host1 and host2 towards host 3, through a router that >> runs my script. I >> need to have 2 LinqUnqueue elements, for host1 and host2 , >> respectively. >> Therefore, to test a configuration with only one >> LinkUnqueue >> element won't >> help me in any way. >> >> >> I have understood you. >> >> If you expect anyone to help you solve your problem, you need >> to >> help narrow down the problem to a minimal bug report. >> >> If you are sure that the problem DOES NOT occur with one >> LinkUnqueue, but DOES occur with two, that would be helpful. >> You >> could report the experiments that brought you to this >> conclusion. >> >> If you are not sure, then you have not created a minimal bug >> report yet. I sent a script that you change to create a >> smaller >> test case. >> >> With your own code, you can test by, for example, only sending >> one >> of the two flows at a time, or whatever else. >> >> >> Could you, at least, explain to me what "scheduled" handler >> (or is it a flag >> of some kind) mean? You can see it when you run Clicky and >> check your >> LinkUnqueue element? >> >> >> "scheduled" is true if the element is rescheduling itself using >> Tasks, and false if it is rescheduling itself using Timers. It >> is >> not very meaningful in this scenario. >> >> Eddie >> >> >> >> >> Thank you very much for your time! >> On Fri, Jun 24, 2011 at 1:09 AM, milos rovcanin >> <ro1208...@gmail.com <mailto:ro1208...@gmail.com> >> <mailto:ro1208...@gmail.com <mailto:ro1208...@gmail.com>>> >> wrote: >> >> >> >> On Thu, Jun 23, 2011 at 8:02 PM, Eddie Kohler >> <koh...@cs.ucla.edu <mailto:koh...@cs.ucla.edu> >> <mailto:koh...@cs.ucla.edu <mailto:koh...@cs.ucla.edu>>> >> wrote: >> >> Milos, >> >> Are you sure this is a bug? >> >> Remember that LinkUnqueue enforces a BANDWIDTH >> limit. >> That means that >> you SHOULD see more smaller packets per second than >> larger ones. >> >> I wrote the following Click script to test the >> enforced bandwidth of >> LinkUnqueue at three packet sizes, first 64, then >> 1000, then 32. The >> observed bandwidths for these three packet sizes >> is: >> >> 10039296 >> 10000000 >> 10000080 >> >> all of which are pretty close to 10000000 bps!! >> >> If you really think this is a bug please provide >> the >> simplest test >> case possible -- preferably involving only one >> LinkUnqueue. >> >> Eddie >> >> >> s :: InfiniteSource(LENGTH 64) >> -> q :: Queue >> -> l :: LinkUnqueue(LATENCY 0, BANDWIDTH >> 10000000 bps) >> -> c :: Counter >> -> Discard; >> >> DriverManager( >> wait 5s, >> write s.active false, >> print $(mul $(c.count) $(s.length) 1.6), // >> 1.6 == 8 bits / 5 sec >> >> write c.reset, >> write q.reset, >> write l.reset, >> write s.length 1000, >> write s.active true, >> wait 5s, >> write s.active false, >> print $(mul $(c.count) $(s.length) 1.6), >> >> write c.reset, >> write q.reset, >> write l.reset, >> write s.length 30, >> write s.active true, >> wait 5s, >> write s.active false, >> print $(mul $(c.count) $(s.length) 1.6), >> ); >> >> >> >> On 06/23/2011 07:00 AM, milos rovcanin wrote: >> >> Greetings to all, >> >> I have noticed an awkward behaviour of the >> LinkUnqueue() element >> when trying >> to send two flows at the same time (UDP/UDP, >> TCP/TCP, UDP/UDP). >> This is, >> pretty much, what my configuration looks like: >> >> ... >> ->Qtag0::Queue(20) >> -> LinkUnqueue(LATENCY 0,BANDWIDTH 13000000 >> bps) >> -> Queue() >> -> [0]output; >> >> ... >> -> Qtag1::Queue(20) >> -> LinkUnqueue(LATENCY 0,BANDWIDTH 9000000 >> bps) >> -> Queue() >> -> [1]output; >> >> and while I am sending at rates lower than the >> ones defined in the >> LinkUnqueue() element, everything seems to be >> working fine. >> Problems start >> to occur when one or both of the flows exceed >> the >> threshold. In >> other words, >> when LinkUnque() starts to shape. Both flow >> rates drop >> significantly, but >> only if the packet size is over 850 bytes! For >> example, if I use >> MSS of 1000 >> bytes, everything work fine even with higher >> rates. >> >> I used Clicky to check the status of the >> LinkUnqueue() element and >> I noticed >> this: >> - Qtag0/Qtag1 lenghts are 1 all the time and >> LinkEnqueue's handler >> "scheduled" is true - when I send smaller packets (the ones >> that cause >> problems) >> - Qtag0/Qtag1 gets immediately full all the >> time >> and LinkEnqueue's >> handler >> "scheduled" is false - when I send larger packets (~850B >> and >> larger) >> >> Does anyone have any idea what could be the >> problem and how to >> solve it? >> >> Thank you in advance! >> >> >> >> >> -- >> Milos Rovcanin >> Department of Information Technology >> Internet Based Communication Networks and Services >> research group (IBCN) >> Ghent University - IBBT >> Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium >> T: +32 9 33 14946 ; T Secr: +32 9 33 14900 >> E: milos.rovca...@intec.ugent.be >> >> <mailto:Milos.Rovcanin@intec.**UGent.be<milos.rovca...@intec.ugent.be> >> > >> <mailto:Milos.Rovcanin@intec._**_UGent.be >> >> <mailto:Milos.Rovcanin@intec.**UGent.be<milos.rovca...@intec.ugent.be> >> >> >> W: www.ibcn.intec.UGent.be >> >> <http://www.ibcn.intec.UGent.**be<http://www.ibcn.intec.UGent.be> >> > >> <http://www.ibcn.intec.UGent._**_be >> >> <http://www.ibcn.intec.UGent.**be<http://www.ibcn.intec.UGent.be> >> >> >> >> >> >> >> >> -- >> Milos Rovcanin >> Department of Information Technology >> Internet Based Communication Networks and Services research >> group (IBCN) >> Ghent University - IBBT >> Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium >> T: +32 9 33 14946 ; T Secr: +32 9 33 14900 >> E: milos.rovca...@intec.ugent.be >> >> <mailto:Milos.Rovcanin@intec.**UGent.be<milos.rovca...@intec.ugent.be> >> > >> <mailto:Milos.Rovcanin@intec._**_UGent.be >> >> <mailto:Milos.Rovcanin@intec.**UGent.be<milos.rovca...@intec.ugent.be> >> >> >> W: www.ibcn.intec.UGent.be <http://www.ibcn.intec.UGent.** >> be <http://www.ibcn.intec.UGent.be>> >> <http://www.ibcn.intec.UGent._**_be >> >> <http://www.ibcn.intec.UGent.**be<http://www.ibcn.intec.UGent.be> >> >> >> >> >> >> >> -- >> Milos Rovcanin >> Department of Information Technology >> Internet Based Communication Networks and Services research group >> (IBCN) >> Ghent University - IBBT >> Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium >> T: +32 9 33 14946 ; T Secr: +32 9 33 14900 >> E: milos.rovca...@intec.ugent.be <mailto:Milos.Rovcanin@intec.** >> UGent.be <milos.rovca...@intec.ugent.be>> >> W: www.ibcn.intec.UGent.be >> <http://www.ibcn.intec.UGent.**be<http://www.ibcn.intec.UGent.be> >> > >> >> >> >> >> -- >> Milos Rovcanin >> Department of Information Technology >> Internet Based Communication Networks and Services research group >> (IBCN) >> Ghent University - IBBT >> Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium >> T: +32 9 33 14946 ; T Secr: +32 9 33 14900 >> E: milos.rovca...@intec.ugent.be <mailto:Milos.Rovcanin@intec.** >> UGent.be <milos.rovca...@intec.ugent.be>> >> W: www.ibcn.intec.UGent.be >> <http://www.ibcn.intec.UGent.**be<http://www.ibcn.intec.UGent.be> >> > >> >> >> >> >> -- >> Milos Rovcanin >> Department of Information Technology >> Internet Based Communication Networks and Services research group (IBCN) >> Ghent University - IBBT >> Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium >> T: +32 9 33 14946 ; T Secr: +32 9 33 14900 >> E: milos.rovca...@intec.ugent.be >> <mailto:Milos.Rovcanin@intec.**UGent.be<milos.rovca...@intec.ugent.be> >> > >> W: www.ibcn.intec.UGent.be >> <http://www.ibcn.intec.UGent.**be<http://www.ibcn.intec.UGent.be> >> > >> >> -- Milos Rovcanin Department of Information Technology Internet Based Communication Networks and Services research group (IBCN) Ghent University - IBBT Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium T: +32 9 33 14946 ; T Secr: +32 9 33 14900 E: milos.rovca...@intec.ugent.be W: www.ibcn.intec.UGent.be _______________________________________________ click mailing list click@amsterdam.lcs.mit.edu https://amsterdam.lcs.mit.edu/mailman/listinfo/click
