[Cerowrt-devel] Network behavior of Moca bridges

[Cerowrt-devel] Network behavior of Moca bridges

[Dave Taht]

I'd like to note that I've got several private reports of really bad,
oft bufferbloated and (also underbuffered!) behavior on moca bridges,
and if you are in a position to benchmark such, more public data on
the problems would be nice.

It generally looks like the same folk that designed homeplug products
were involved in moca, with similar behaviors as described below with
hardware flow control and the like, in addition to possible
underbuffering and issues with shared media backoffs...

http://caia.swin.edu.au/reports/130121A/CAIA-TR-130121A.pdf

http://caia.swin.edu.au/reports/130417A/CAIA-TR-130417A.pdf

But we lack hard public data on how the moca devices actually work or
public testing.

Re: [Cerowrt-devel] Network behavior of Moca bridges

[Aaron Wood]

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

In about 2 months, I'll have my hands on some HomePlugAV devices that I can
do extensive testing with.  My previous tests were showing very, very large
bufferbloat, when used on poor links (2000ms of buffering and growing over
a 1-2 minute rrul test that wasn't able to get over 10Mbps due to SF
Victorian wiring issues).

-Aaron



On Tue, Apr 15, 2014 at 11:05 PM, Dave Taht <dave.taht@gmail.com> wrote:

> I'd like to note that I've got several private reports of really bad,
> oft bufferbloated and (also underbuffered!) behavior on moca bridges,
> and if you are in a position to benchmark such, more public data on
> the problems would be nice.
>
> It generally looks like the same folk that designed homeplug products
> were involved in moca, with similar behaviors as described below with
> hardware flow control and the like, in addition to possible
> underbuffering and issues with shared media backoffs...
>
> http://caia.swin.edu.au/reports/130121A/CAIA-TR-130121A.pdf
>
> http://caia.swin.edu.au/reports/130417A/CAIA-TR-130417A.pdf
>
> But we lack hard public data on how the moca devices actually work or
> public testing.
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

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

Re: [Cerowrt-devel] Network behavior of Moca bridges

[Frits Riep]

Dave,

I am willing to help.  It is interesting information.  Also that the powerline extenders have the same issue, which is really unfortunate.  To do any testing, I will need to install a second moca adapter as I currently have only one installed to connect to the TV set top boxed from Verizon FIOS.

Other than testing for latency through a Moca bridged connection, vs directly connected through Ethernet, is there any specific recommendation on how to test to get meaningful information?

Btw, the current release of CeroWRT using fq_codel sqm is excellent at controlling bufferbloat both on the wired and wireless connections - so kudos to all the hard work that has been done!  Only a few days so far, but I am very impressed with the results.  (hopefully we are about to call this the new stable).

I may not be able to test the moca setup until the weekend as all of my clients who waited forever to replace their XP systems now find it to be critical and so we have a very high number of small businesses replacing xp systems with our currently recommended Windows 7 Pro x64.

I think in most cases the Moca bridges are primarily feeding streaming video and control info to set top boxes and I would think bufferbloat would be not a real high concern in those applications.

Powerline adaptors are used pretty often to extend Ethernet to systems which are difficult or expensive to wire to, and in situations where wireless signals are weak or unreliable.  Bufferbloat for these devices would be much more problematic for these applications as it includes web browsing and other latency sensitive uses.

Frits

-----Original Message-----
From: Dave Taht [mailto:dave.taht@gmail.com] 
Sent: Tuesday, April 15, 2014 5:06 PM
To: Frits Riep
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: Network behavior of Moca bridges

I'd like to note that I've got several private reports of really bad, oft bufferbloated and (also underbuffered!) behavior on moca bridges, and if you are in a position to benchmark such, more public data on the problems would be nice.

It generally looks like the same folk that designed homeplug products were involved in moca, with similar behaviors as described below with hardware flow control and the like, in addition to possible underbuffering and issues with shared media backoffs...

http://caia.swin.edu.au/reports/130121A/CAIA-TR-130121A.pdf

http://caia.swin.edu.au/reports/130417A/CAIA-TR-130417A.pdf

But we lack hard public data on how the moca devices actually work or public testing.

Re: [Cerowrt-devel] Network behavior of Moca bridges

[Chris Lawrence]

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

For what it's worth I have a home MoCA network (1 TiVo Premiere XL4 and 2
ActionTec MoCA adapters); I'm not sure how to go about benchmarking it but
I'd be happy to help. Performance-wise I haven't noticed any issues, even
in interactive use (often ssh over wifi to CeroWRT to MoCA to my Linux
desktop), and a definite improvement over the first-generation Panasonic
powerline network I was using before.


Chris


On Wed, Apr 16, 2014 at 7:58 AM, Frits Riep <riep@riepnet.com> wrote:

> Dave,
>
> I am willing to help.  It is interesting information.  Also that the
> powerline extenders have the same issue, which is really unfortunate.  To
> do any testing, I will need to install a second moca adapter as I currently
> have only one installed to connect to the TV set top boxed from Verizon
> FIOS.
>
> Other than testing for latency through a Moca bridged connection, vs
> directly connected through Ethernet, is there any specific recommendation
> on how to test to get meaningful information?
>
> Btw, the current release of CeroWRT using fq_codel sqm is excellent at
> controlling bufferbloat both on the wired and wireless connections - so
> kudos to all the hard work that has been done!  Only a few days so far, but
> I am very impressed with the results.  (hopefully we are about to call this
> the new stable).
>
> I may not be able to test the moca setup until the weekend as all of my
> clients who waited forever to replace their XP systems now find it to be
> critical and so we have a very high number of small businesses replacing xp
> systems with our currently recommended Windows 7 Pro x64.
>
> I think in most cases the Moca bridges are primarily feeding streaming
> video and control info to set top boxes and I would think bufferbloat would
> be not a real high concern in those applications.
>
> Powerline adaptors are used pretty often to extend Ethernet to systems
> which are difficult or expensive to wire to, and in situations where
> wireless signals are weak or unreliable.  Bufferbloat for these devices
> would be much more problematic for these applications as it includes web
> browsing and other latency sensitive uses.
>
> Frits
>
> -----Original Message-----
> From: Dave Taht [mailto:dave.taht@gmail.com]
> Sent: Tuesday, April 15, 2014 5:06 PM
> To: Frits Riep
> Cc: cerowrt-devel@lists.bufferbloat.net
> Subject: Network behavior of Moca bridges
>
> I'd like to note that I've got several private reports of really bad, oft
> bufferbloated and (also underbuffered!) behavior on moca bridges, and if
> you are in a position to benchmark such, more public data on the problems
> would be nice.
>
> It generally looks like the same folk that designed homeplug products were
> involved in moca, with similar behaviors as described below with hardware
> flow control and the like, in addition to possible underbuffering and
> issues with shared media backoffs...
>
> http://caia.swin.edu.au/reports/130121A/CAIA-TR-130121A.pdf
>
> http://caia.swin.edu.au/reports/130417A/CAIA-TR-130417A.pdf
>
> But we lack hard public data on how the moca devices actually work or
> public testing.
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



-- 
Chris Lawrence <lordsutch@gmail.com>

Website: http://www.cnlawrence.com/

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

Re: [Cerowrt-devel] Network behavior of Moca bridges

[Dave Taht]

Well, the simplest basic test is a topology like this:

source -> moca bridge -> moca cable -> moca bridge -> sink

and any of a variety of basic, and latency under load tests from the
rrul suite, and/or tests from the homeplug papers I referenced
earlier. Packet captures would be good in case of weirdnesses.

I don't know to what extent the tivos nowadays are hackable to use as
a sink (cross compile netperf head?),
but you can put a laptop on each end over ethernet, given you already
have the gear....

While characterising the behavior of this simple topology would be
very valuable, I confess to being
more interested in what happens on moca under contention, as it is a
shared, not switched, medium,
with an architecture that looks more like original ethernet or arcnet
or present day wireless. That included
interesting things like random backoff on collisions (but I confess to
not knowing much about how
moca does things in general) which led to low sustained throughput in
the pre-switched era and much debate over alternatives like SNA and
token ring.

Simplest topology for that is:

source 1
          sink 3
              -> moca bridge -> moca cable -> moca bridge ->
source 2
          sink 4

We have some specific tests in the rrul suite for testing scenarios
like this, notably
the "rtt_fair" string of tests.



On Thu, Apr 17, 2014 at 12:09 PM, Chris Lawrence <lordsutch@gmail.com> wrote:
> For what it's worth I have a home MoCA network (1 TiVo Premiere XL4 and 2
> ActionTec MoCA adapters); I'm not sure how to go about benchmarking it but
> I'd be happy to help. Performance-wise I haven't noticed any issues, even in
> interactive use (often ssh over wifi to CeroWRT to MoCA to my Linux
> desktop), and a definite improvement over the first-generation Panasonic
> powerline network I was using before.
>
>
> Chris
>
>
> On Wed, Apr 16, 2014 at 7:58 AM, Frits Riep <riep@riepnet.com> wrote:
>>
>> Dave,
>>
>> I am willing to help.  It is interesting information.  Also that the
>> powerline extenders have the same issue, which is really unfortunate.  To do
>> any testing, I will need to install a second moca adapter as I currently
>> have only one installed to connect to the TV set top boxed from Verizon
>> FIOS.
>>
>> Other than testing for latency through a Moca bridged connection, vs
>> directly connected through Ethernet, is there any specific recommendation on
>> how to test to get meaningful information?
>>
>> Btw, the current release of CeroWRT using fq_codel sqm is excellent at
>> controlling bufferbloat both on the wired and wireless connections - so
>> kudos to all the hard work that has been done!  Only a few days so far, but
>> I am very impressed with the results.  (hopefully we are about to call this
>> the new stable).
>>
>> I may not be able to test the moca setup until the weekend as all of my
>> clients who waited forever to replace their XP systems now find it to be
>> critical and so we have a very high number of small businesses replacing xp
>> systems with our currently recommended Windows 7 Pro x64.
>>
>> I think in most cases the Moca bridges are primarily feeding streaming
>> video and control info to set top boxes and I would think bufferbloat would
>> be not a real high concern in those applications.
>>
>> Powerline adaptors are used pretty often to extend Ethernet to systems
>> which are difficult or expensive to wire to, and in situations where
>> wireless signals are weak or unreliable.  Bufferbloat for these devices
>> would be much more problematic for these applications as it includes web
>> browsing and other latency sensitive uses.
>>
>> Frits
>>
>> -----Original Message-----
>> From: Dave Taht [mailto:dave.taht@gmail.com]
>> Sent: Tuesday, April 15, 2014 5:06 PM
>> To: Frits Riep
>> Cc: cerowrt-devel@lists.bufferbloat.net
>> Subject: Network behavior of Moca bridges
>>
>> I'd like to note that I've got several private reports of really bad, oft
>> bufferbloated and (also underbuffered!) behavior on moca bridges, and if you
>> are in a position to benchmark such, more public data on the problems would
>> be nice.
>>
>> It generally looks like the same folk that designed homeplug products were
>> involved in moca, with similar behaviors as described below with hardware
>> flow control and the like, in addition to possible underbuffering and issues
>> with shared media backoffs...
>>
>> http://caia.swin.edu.au/reports/130121A/CAIA-TR-130121A.pdf
>>
>> http://caia.swin.edu.au/reports/130417A/CAIA-TR-130417A.pdf
>>
>> But we lack hard public data on how the moca devices actually work or
>> public testing.
>>
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
>
>
> --
> Chris Lawrence <lordsutch@gmail.com>
>
> Website: http://www.cnlawrence.com/
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

Re: [Cerowrt-devel] Network behavior of Moca bridges

[Dave Taht]

Obviously my ascii art skills are in decline in an age when I don't know
when I have 72 chars to deal with. Trying the more complex topology
again:

 source 1                                   source 2
       |                                              |
  moca bridge  1                        moca bridge 2
                      \                        /
                       \                      /
                      shared moca cable
                                   |
                      moca device or bridges


Or your more classic:

 source 1                                   source 2
       |                                              |
  moca bridge  1                        moca bridge 2
                      \                        /
                       \                      /
                      shared moca cable
                       /                       \
                      /                         \
  moca bridge  3                        moca bridge 4
       |                                           |
     sink 5                                  sink 6

In my world the distinction between source and sink
is kind of vague as all traffic is bidirectional, whether that
be as basic as an ack, or a file being streamed elsewhere.

I am under the impression however that moca can receive
multicast video streams, which have no equivalent.

-- 
Dave Täht