From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-f43.google.com (mail-yw0-f43.google.com [209.85.213.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 8E153200681 for ; Wed, 3 Aug 2011 07:52:27 -0700 (PDT) Received: by ywt2 with SMTP id 2so775536ywt.16 for ; Wed, 03 Aug 2011 08:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=QjQL9ZLrZVuxGl76kNuIaQ0wKuHqSLg8H7eVFYZNfpI=; b=uo19FQ+vfetERa+8O2N2mdgTrtcXkyZsLkYVZZcxRvSeIHBHa+/E1fWO8qgy6VmRX8 WrL6r9OxA6NBMqUOO9Gi1chD6NjMSkPTRpnMyKYgMyfA2A6KSxcOx6VsKj0wtPqLK07L YIW0hJIMMeGF+cWnYpJJbHX+rfB2ERdEfO+Jc= MIME-Version: 1.0 Received: by 10.42.29.198 with SMTP id s6mr5292643icc.296.1312385958789; Wed, 03 Aug 2011 08:39:18 -0700 (PDT) Received: by 10.42.217.194 with HTTP; Wed, 3 Aug 2011 08:39:18 -0700 (PDT) Date: Wed, 3 Aug 2011 09:39:18 -0600 Message-ID: From: Dave Taht To: bloat , Jacopo Cesareo Content-Type: multipart/alternative; boundary=20cf303ea1d4e1c43704a99baa53 Subject: [Bloat] Testing wireless broadcast/multicast within cerowrt X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 14:52:28 -0000 --20cf303ea1d4e1c43704a99baa53 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Given how devastatingly effective my call to the list for help was, on: http://www.bufferbloat.net/issues/216 http://www.bufferbloat.net/issues/195 (195 is NAILED right now, 216 is making serious progress - see the bug reports for more details) I figure that perhaps leveraging y'all expertise to take a harder look at multicast - which we've discussed extensively here, would be good. I picked uftp out of thin air as a possibly useful tool for analyzing multicast behavior on wired and multiple radios simultaneously. It's one of the few multicast tools that is widely used. One really excellent suggestion that has gone by was to break with the 802.11 standard and multicast at the highest rate all the stations are know= n to accept, but it would be good to have some tool - not necessarily uftp - to tweak at it. I have no idea as to the overall state of multicast support in Linux. Most multicast research died ages ago, but 'turning up the volume' in this way may lend some insight into the problems we are having with the more common 'ANT' multicast packets like ARP, etc. I've been working with a grad student over at princeton (cc'd) on getting uftp to work right, but we're running into issues that I don't have the spare cycles to resolve right now. Maybe I missed something in the kernel build? Maybe there's something weird about jacobo's laptop or the router itself? (I've already asked dennis for insight) http://www.bufferbloat.net/issues/206 My dream, in trying to use uftp for this, is to have a knob I can turn up o= r down for bandwidth for almost isosyncronous and simultaneous! multicast streams running across gigE, various forms of 802.11abgn, on multiple radios, all at the same time - to analyze, and get more insight as to what'= s going on - not just with basic multicast - but as I've been seeing broadcas= t like arp and dhcp failing everywhere I've encountered a 'n' network, of late, to be able to take a hard look at all of it. I've thrown out the codebase that cerowrt RC4 was based on and development builds are currently taking place here: http://huchra.bufferbloat.net/~andrewm/cerowrt/ My problem at the moment could be something basic - a missing config in the build? - but it would be nice to know if uftp works right on more conventional systems before working harder at it. Complete configuration info on how to use it, and it's performance, etc, would be useful. And suggestions on other multicast/broadcast tools generating data worth analyzing is highly desired. --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com --20cf303ea1d4e1c43704a99baa53 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Given how devastatingly effective my call to the list for help was, on:
=
http://www.bufferbloa= t.net/issues/216
h= ttp://www.bufferbloat.net/issues/195

(195 is NAILED right now, 216 is making serious progress - see the bug = reports for more details)

I figure that perhaps leveraging y'all= expertise to take a harder look at multicast - which we've discussed e= xtensively here, would be good.

I picked uftp out of thin air as a possibly useful tool for analyzing m= ulticast behavior on wired and multiple radios simultaneously. It's one= of the few multicast tools that is widely used.

One really excellen= t suggestion that has gone by was to break with the 802.11 standard and mul= ticast at the highest rate all the stations are known to accept, but it wou= ld be good to have some tool - not necessarily uftp - to tweak at it.

I have no idea as to the overall state of multicast support in Linux. M= ost multicast research died ages ago, but 'turning up the volume' i= n this way may lend some insight into the problems we are having with the m= ore common 'ANT' multicast packets like ARP, etc.

I've been working with a grad student over at princeton (cc'd) = on=20 getting uftp to work right, but we're running into issues that I don= 9;t=20 have the spare cycles to resolve right now. Maybe I missed something in=20 the kernel build? Maybe there's something weird about jacobo's lapt= op or the router itself? (I've already asked dennis for insight)

htt= p://www.bufferbloat.net/issues/206

My dream, in trying to use uftp for this, is to have a knob I can turn up=20 or down for bandwidth for almost isosyncronous and simultaneous!=20 multicast streams running across gigE, various forms of 802.11abgn, on mult= iple radios, all at the same time - to=20 analyze, and get more insight as to what's going on - not just with=20 basic multicast - but as I've been seeing broadcast like arp and dhcp= =20 failing everywhere I've encountered a 'n' network, of late, to = be able to take a hard look at all of it.

I've thrown out the codebase that cerowrt RC4 was based on and deve= lopment builds are currently taking place here:

http://huchra.bufferbloat.net/~andrewm/cerowrt/

My prob= lem at the moment could be something basic - a missing config in the build?= - but it would be nice to know if uftp works right on more conventional sy= stems before working harder at it.

Complete configuration info on how to use it, and it's performance,= etc, would be useful.

And suggestions on other multicast/broadcast = tools generating data worth analyzing is highly desired.


--
Dave T=E4ht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blog= spot.com
--20cf303ea1d4e1c43704a99baa53--