<div dir="ltr">10Mbps/32 ~= 300kbps<div><br></div><div>Does the VoIP stream use more than that 300kbps?</div><div>In the ideal case as long as the sparse flow has a rate which is lower than the fair rate</div><div>the optimization should work. Otherwise the optimization might not as close to ideal as possible.</div><div><br></div><div>Luca</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 17, 2018 at 11:42 AM, Toke Høiland-Jørgensen <span dir="ltr"><<a href="mailto:toke@toke.dk" target="_blank">toke@toke.dk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've been trying to show the benefit of Cake's diffserv mode and came<br>
across a few odd results along the way. Attached are two plots of a test<br>
run with 32 TCP flows competing with a single EF-marked VoIP flow.<br>
<br>
The puzzling points are:<br>
<br>
- There is not difference between Cake in diffserv mode and non-diffserv<br>
  mode. For FQ-CoDel, 32 flows (on a 10Mbit link) are clearly too many<br>
  to keep the VoIP flow prioritised through the sparse flow<br>
  optimisation. This is to be expected. However, Cake (in besteffort<br>
  mode) does not show this tendency. Why not?<br>
<br>
- The TCP RTT of the 32 flows is *way* higher for Cake. FQ-CoDel<br>
  controls TCP flow latency to around 65 ms, while for Cake it is all<br>
  the way up around the 180ms mark. Is the Codel version in Cake too<br>
  lenient, or what is going on here?<br>
<span class="HOEnZb"><font color="#888888"><br>
-Toke<br>
<br>
<br>
</font></span><br>______________________________<wbr>_________________<br>
Cake mailing list<br>
<a href="mailto:Cake@lists.bufferbloat.net">Cake@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/cake" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/cake</a><br>
<br></blockquote></div><br></div>