Re: [Cake] COBALT implementation in ns-3 with results under different traffic scenarios
Hi Jonathan, Thanks! First, we noticed that cobalt_cache_init method was not implemented in ns-3 COBALT, so we implemented it (but this wasn't the main reason for the wrong behaviour). Later, we found that the data types used in the implementation of COBALT in ns-3 were different from those used in Linux. e.g., uint32_t was used instead of int64_t for the variables with datatype ktime_t in Linux. Results improved considerably after these changes. We will update the wiki with latest results. Regards, Shefali Gupta Jendaipou Palmei On Wed 23 Jan 2019, 9:53 p.m. Jonathan Morton > On 23 Jan, 2019, at 6:19 pm, Shefali Gupta > wrote: > > > > We believe we have spotted the issue now. The new plot is attached below. > > That does look considerably improved. What was the problem in the end? > > Now would be a good time to regenerate all the test graphs, and make sure > there are results for each test for each qdisc tested. Ideally all graphs > should be generated from the same run(s), to ensure their data is mutually > consistent. > > - Jonathan Morton > > ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
Re: [Cake] COBALT implementation in ns-3 with results under different traffic scenarios
> On 23 Jan, 2019, at 6:19 pm, Shefali Gupta wrote: > > We believe we have spotted the issue now. The new plot is attached below. That does look considerably improved. What was the problem in the end? Now would be a good time to regenerate all the test graphs, and make sure there are results for each test for each qdisc tested. Ideally all graphs should be generated from the same run(s), to ensure their data is mutually consistent. - Jonathan Morton ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
Re: [Cake] COBALT implementation in ns-3 with results under different traffic scenarios
Hi Jonathan, We believe we have spotted the issue now. The new plot is attached below. Does it look as expected? [image: Updated_Graphs.png] Thanks and regards, Shefali Gupta Jendaipou Palmei On Mon, Jan 21, 2019 at 6:27 PM Jonathan Morton wrote: > > On 21 Jan, 2019, at 1:35 pm, Shefali Gupta > wrote: > > > > We re-looked into the COBALT implementation to understand why it drops > the first packet later than CoDel. > > > > There was a bug in the data that was collected in 'drop timestamp > files'. We tried using a different approach to store packet drop times, and > now we see that COBALT indeed drops the first packet prior to CoDel's first > packet drop (image below). So the issue was that our previous approach of > storing the packet drop times in a file was not correct. > > > > Let us know your opinion. > > Okay, good catch. > > But the more serious problem is with the pattern of drops, which presently > looks much more like BLUE activity (random) than Codel (ramping > frequency). That seems to be unchanged in your new graph. > > Have you made any progress towards finding out why the queue is apparently > too short? Perhaps log the actual length of the queue when overflow drops > occur. > > - Jonathan Morton > > ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
