Hi George<div>Thank you for your reply and helpful comments. You are right. There are too many players at hand on my setup’s datapath.</div><div><br></div><div>I will try to set up more controlled experiments.</div><div><br></div><div>Thanks </div><div>Best</div><div>Azin<br><div><br><div class="gmail_quote"><div>On Fri, Jan 18, 2019 at 12:24 AM George Lambert &lt;<a href="mailto:marchon@gmail.com">marchon@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I have been on this list for a long time, but I don&#39;t normally respond.<div><br></div><div>With that said, you should keep in mind that when you are using a VM / there is a software IP stack that is touching and playing with your packets. </div><div><br></div><div>I would consider if it is easy to try the following to give yourself a more controlled test environment. </div><div><br></div><div>1. run a USB OS without a VM on raw metal to remove the extra network routing stacks</div><div>2. directly cable into your router to eliminate any potential &quot;802.11&quot; interference from other devices and neighbors </div><div>3. see if you get the same/similar results </div><div>4. For optimal test results - PowerCycle your router to be sure that it has freshly reset it&#39;s memory - </div><div>5. Do a traceroute to see if your connection is experiencing any interference / packetloss in the route between yourself and the remote server. <br></div><div><br></div><div>George -</div><div>ps: If you would like to google hangout or <a href="http://zoom.us" target="_blank">zoom.us</a> to check the configuration / I could spend a few minutes with you.</div></div><br><div class="gmail_quote"></div><div class="gmail_quote"><div class="m_-694961133897404375gmail_attr">On Thu, Jan 17, 2019 at 11:25 PM Azin Neishaboori &lt;<a href="mailto:azin.neishaboori@gmail.com" target="_blank">azin.neishaboori@gmail.com</a>&gt; wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Dear all<div>I have some contradictory results on my WiFi link. I run flent&#39;s rrul test using several bufferbloat mitigation algorithms, and see that, compared to FQ_codel, TCP BBR, etc., a simple prioritized ACK works the best. Why is that I have no idea. I also am not clear as to why using BBR on the client end increases the download throughput, but not upload (still doing worse than prioritized ACK on cubic in download anyway). Attached please see the plot. </div><div>What am I missing?</div><div><br></div><div>My setup is pretty simple. I am on WiFi on my PC, and run flent on an Ubuntu VM on a virtual machine, and connect to <a href="http://netperf.bufferbloat.net" target="_blank">netperf.bufferbloat.net</a>. All configurations are done on my VM end of course. </div><div><br></div><div>Any help/hint would be appreciated.</div><div><br></div><div>Thanks a lot</div><div>Best<br>Azin</div></div></blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
_______________________________________________<br>
Bloat-devel mailing list<br>
<a href="mailto:Bloat-devel@lists.bufferbloat.net" target="_blank">Bloat-devel@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat-devel" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/bloat-devel</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div class="m_-694961133897404375gmail_signature">P THINK BEFORE PRINTING: is it really necessary?<br><br>This e-mail and its attachments are confidential and solely for the<br>intended addressee(s). Do not share or use them without approval. If received in error, contact the sender<br>and delete them.</div>
</blockquote></div></div></div>