[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 at gmail.com] 
Sent: Tuesday, April 15, 2014 5:06 PM
To: Frits Riep
Cc: cerowrt-devel at 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.