contradictory WiFi flent results

contradictory WiFi flent results

[Azin Neishaboori]

[-- Attachment #1.1: Type: text/plain, Size: 736 bytes --]

Dear all
I have some contradictory results on my WiFi link. I run flent'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.
What am I missing?

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 netperf.bufferbloat.net. All
configurations are done on my VM end of course.

Any help/hint would be appreciated.

Thanks a lot
Best
Azin

[-- Attachment #1.2: Type: text/html, Size: 917 bytes --]

[-- Attachment #2: IMG_5945.JPG --]
[-- Type: image/jpeg, Size: 132917 bytes --]

Re: contradictory WiFi flent results

[Jonathan Morton]

> On 18 Jan, 2019, at 6:25 am, Azin Neishaboori <azin.neishaboori@gmail.com> wrote:
> 
> 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 netperf.bufferbloat.net.

From a technical point of view, that really isn't a "simple" setup.  The very fact that you're running Linux in a VM means it probably doesn't have direct control of the wifi hardware - rather, the host OS does, and I very much doubt that Windows is very intelligent about it.  Then your path involves an awful lot of Internet infrastructure on the way to the remote server and back.

So your simple prioritised ack is the solution that works, because it's the only solution that actually does anything in your setup.

 - Jonathan Morton

Re: contradictory WiFi flent results

[Azin Neishaboori]

[-- Attachment #1: Type: text/plain, Size: 2668 bytes --]

Hi George
Thank you for your reply and helpful comments. You are right. There are too
many players at hand on my setup’s datapath.

I will try to set up more controlled experiments.

Thanks
Best
Azin

On Fri, Jan 18, 2019 at 12:24 AM George Lambert <marchon@gmail.com> wrote:

> I have been on this list for a long time, but I don't normally respond.
>
> 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.
>
> I would consider if it is easy to try the following to give yourself a
> more controlled test environment.
>
> 1. run a USB OS without a VM on raw metal to remove the extra network
> routing stacks
> 2. directly cable into your router to eliminate any potential "802.11"
> interference from other devices and neighbors
> 3. see if you get the same/similar results
> 4. For optimal test results - PowerCycle your router to be sure that it
> has freshly reset it's memory -
> 5. Do a traceroute to see if your connection is experiencing any
> interference / packetloss in the route between yourself and the remote
> server.
>
> George -
> ps: If you would like to google hangout or zoom.us to check the
> configuration / I could spend a few minutes with you.
>
> On Thu, Jan 17, 2019 at 11:25 PM Azin Neishaboori <
> azin.neishaboori@gmail.com> wrote:
>
>> Dear all
>> I have some contradictory results on my WiFi link. I run flent'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.
>> What am I missing?
>>
>> 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 netperf.bufferbloat.net.
>> All configurations are done on my VM end of course.
>>
>> Any help/hint would be appreciated.
>>
>> Thanks a lot
>> Best
>> Azin
>>
> _______________________________________________
>> Bloat-devel mailing list
>> Bloat-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat-devel
>>
>
>
> --
> P THINK BEFORE PRINTING: is it really necessary?
>
> This e-mail and its attachments are confidential and solely for the
> intended addressee(s). Do not share or use them without approval. If
> received in error, contact the sender
> and delete them.
>

[-- Attachment #2: Type: text/html, Size: 3993 bytes --]

Re: contradictory WiFi flent results

[Azin Neishaboori]

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]

Hi Jonathan
Thank you for your reply and insight. You are right about my setup.

Just wondering if you have some insight into why I get significantly better
download (not uplad) throughput by all other methods over cubic, including
bbr. I mean, bbr on the sender side would mean I am supposed to get
improvement on upload. Granted that my poor setup could distort any gains
on upload by bbr, why do I get throughput gains on download?

Thank you for your help
Best
Azin


On Fri, Jan 18, 2019 at 1:27 AM Jonathan Morton <chromatix99@gmail.com>
wrote:

> > On 18 Jan, 2019, at 6:25 am, Azin Neishaboori <
> azin.neishaboori@gmail.com> wrote:
> >
> > 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 netperf.bufferbloat.net.
>
> From a technical point of view, that really isn't a "simple" setup.  The
> very fact that you're running Linux in a VM means it probably doesn't have
> direct control of the wifi hardware - rather, the host OS does, and I very
> much doubt that Windows is very intelligent about it.  Then your path
> involves an awful lot of Internet infrastructure on the way to the remote
> server and back.
>
> So your simple prioritised ack is the solution that works, because it's
> the only solution that actually does anything in your setup.
>
>  - Jonathan Morton
>
>

[-- Attachment #2: Type: text/html, Size: 1880 bytes --]

Re: contradictory WiFi flent results

[Jonathan Morton]

> On 18 Jan, 2019, at 10:05 am, Azin Neishaboori <azin.neishaboori@gmail.com> wrote:
> 
> Just wondering if you have some insight into why I get significantly better download (not uplad) throughput by all other methods over cubic, including bbr. I mean, bbr on the sender side would mean I am supposed to get improvement on upload. Granted that my poor setup could distort any gains on upload by bbr, why do I get throughput gains on download?

Is that measurement repeatable?  Conditions on the path may have changed between the time you did a CUBIC run and later, with other algorithms.  That's an unavoidable hazard of measuring in such a complex environment.

 - Jonathan Morton