On Tue, Dec 4, 2018 at 7:02 AM Jonathan Morton <[email protected]> wrote:
>
> > On 4 Dec, 2018, at 12:31 pm, Jendaipou Palmei <[email protected]> 
> > wrote:
> >
> > We have uploaded the plots for the 'count' variable of COBALT (with a 
> > segment size of 1500 and 1000 bytes).
> >
> > Link: https://github.com/Daipu/COBALT/wiki/Cobalt-Drop-Count
> >
> > We have not yet implemented ECN feature in COBALT, so packets are currently 
> > dropped instead of being marked.
> >
> > Are these the plots that you were referring to?
>
> More-or-less, yes, though these actually show an internal state variable of 
> the Codel algorithm rather than the actual number of marks/drops per time 
> interval.  I was hoping to see similar graphs for the reference-Codel and PIE 
> runs, since we can gain more insight from that, and PIE doesn't have an 
> internal "count" variable that corresponds with Codel.  Nevertheless, the 
> view into "count" behaviour is interesting in itself, and I'd like to see the 
> corresponding graphs from reference Codel.
>
> An artefact visible in these graphs is an apparent lack of sampling while not 
> in the dropping state.  Thus you seem to have a gradual ramp from 0 to 1 
> count over the several seconds interval between activations, though in fact 
> the variable is discrete.  It would be better to show that transition more 
> precisely.
>
> For study, it is also often helpful to zoom in on small time intervals to see 
> the dynamic behaviour of the algorithm, particularly during the transition 
> from slow-start to steady-state, where there is seemingly a big difference 
> between reference Codel and COBALT.

I'm loving the slow start result.

>
> Another interesting graph to produce for each algorithm and traffic type is 
> the instantaneous throughput of each flow.  This offers insight into the 
> relative fairness of each algorithm, and might help to explain the anomaly 
> seen with 1000-byte packets and COBALT.  Usually this graph also reveals, 
> through the shape of each throughput curve, which CC algorithm is in use - 
> currently I'm guessing NewReno.  CUBIC and CTCP, which are also in common 
> use, would behave differently.

a file showing the timestamp of each drop would be easier to post process.

>
>  - Jonathan Morton
>


-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake

Reply via email to