Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: "Frits Riep" <riep@riepnet.com>
To: "'Dave Taht'" <dave.taht@gmail.com>
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] Network behavior of Moca bridges
Date: Wed, 16 Apr 2014 07:58:22 -0400	[thread overview]
Message-ID: <012a01cf596b$2ad971e0$808c55a0$@com> (raw)
In-Reply-To: <CAA93jw6K6DAxbLCPYxG8AWZLjj8_08nhjyjRWTNdP-WjfcOPgQ@mail.gmail.com>

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.


  parent reply	other threads:[~2014-04-16 11:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-15 21:05 Dave Taht
2014-04-15 21:30 ` Aaron Wood
2014-04-16 11:58 ` Frits Riep [this message]
2014-04-17 19:09   ` Chris Lawrence
2014-04-17 19:48     ` Dave Taht
2014-04-17 20:03       ` Dave Taht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='012a01cf596b$2ad971e0$808c55a0$@com' \
    --to=riep@riepnet.com \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=dave.taht@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox