<div dir="ltr">Hi Jonathan,<div><br></div><div>We believe we have spotted the issue now. The new plot is attached below.</div><div><br></div><div>Does it look as expected?</div><div class=""><img src="cid:ii_jr9e57ar0" alt="Updated_Graphs.png" class="" style="margin-right: 0px;" width="934" height="619"></div><div class=""><br></div><div class="">Thanks and regards,</div><div class="">Shefali Gupta</div><div class="">Jendaipou Palmei<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 21, 2019 at 6:27 PM Jonathan Morton <<a href="mailto:chromatix99@gmail.com">chromatix99@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> On 21 Jan, 2019, at 1:35 pm, Shefali Gupta <<a href="mailto:shefaligups11@gmail.com" target="_blank">shefaligups11@gmail.com</a>> wrote:<br>
> <br>
> We re-looked into the COBALT implementation to understand why it drops the first packet later than CoDel.<br>
> <br>
> 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.<br>
> <br>
> Let us know your opinion.<br>
<br>
Okay, good catch.<br>
<br>
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.<br>
<br>
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.<br>
<br>
 - Jonathan Morton<br>
<br>
</blockquote></div>