From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 27F6621F22E for ; Thu, 17 Apr 2014 12:49:02 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id x13so852645wgg.2 for ; Thu, 17 Apr 2014 12:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=JAKD4oxzaW46rEcEq71YRkGLOyF6ldBqV5tRH9ewlvY=; b=I4Wn/c2Cs2fgMahirpj2evo1zEJVeB3JjdpVpb5cwnYWpJDQAzDO5Fn42b+0HIEtL9 /D+cjrgDwaLdTPLw0ArsubNxMJ1rn2Qq9QMeJPVAGUaZd1rVF8ridLbfHz1FMdkRdJg9 SLpmOFgzJUZ7b5On0kmCAITYV5/ia5TE5pacsSRruZYkTwZNoYMYR5tN3WiYslrdG+z/ FKG30gKPVwUDX/eEIFi1b55aYXQiBgxZ/MqUG9Xywr3PJYJrXqnxN7gJN2wzuk280gzk mJQMz+XUIbfFXH7wv+XacKPs0vQBxpVYcyJB+MsdqtU8Fom/OvUmUFWg4n2Igb72ZlY9 PHnQ== MIME-Version: 1.0 X-Received: by 10.180.19.167 with SMTP id g7mr13637211wie.46.1397764139880; Thu, 17 Apr 2014 12:48:59 -0700 (PDT) Received: by 10.216.177.10 with HTTP; Thu, 17 Apr 2014 12:48:59 -0700 (PDT) In-Reply-To: References: <012a01cf596b$2ad971e0$808c55a0$@com> Date: Thu, 17 Apr 2014 12:48:59 -0700 Message-ID: From: Dave Taht To: Chris Lawrence Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [Cerowrt-devel] Network behavior of Moca bridges X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 19:49:02 -0000 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 wrot= e: > 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 bu= t > 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 wrote: >> >> Dave, >> >> I am willing to help. It is interesting information. Also that the >> powerline extenders have the same issue, which is really unfortunate. T= o 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 recommendatio= n 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 t= his >> 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 wo= uld >> 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, of= t >> bufferbloated and (also underbuffered!) behavior on moca bridges, and if= you >> are in a position to benchmark such, more public data on the problems wo= uld >> be nice. >> >> It generally looks like the same folk that designed homeplug products we= re >> involved in moca, with similar behaviors as described below with hardwar= e >> flow control and the like, in addition to possible underbuffering and is= sues >> 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 > > Website: http://www.cnlawrence.com/ > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article