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

[Dave Taht <dave.taht@gmail.com>]

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