From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (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 3365A21F1BA for ; Thu, 17 Jan 2013 11:28:09 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id 9so1475244iec.16 for ; Thu, 17 Jan 2013 11:28:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=m5tYkikU6uC+HL10cCpFvrT192ZuooBhymE+3kWXa8s=; b=pXh9Wr1PVrL5pT2C294M5tJWsk25NLTxn3zItfjCtj9+GPRnsjwfrmg5D2sBq1muNN 3pPuJR8LAYrFDDcQVni5F4m3u8CEVmaCNSG/sdHYewYVO8rc81g7siHd/5Ms2+X/+F9N JpklfrJMG+ZUVkqikAkviaQeNnBDMQMZN2hatbuXVe4sAJDM7Uciulwvi2/w8BkpuzkQ xV8v+UcuFmwAu3jY581r6AJiM9B7DTdfmfVPtYSMfhQJhiKaboiIRzxiBxQ4qAEmPlCU kxYiLSEVhsDVLgBzUy0cizSmNuRyU06vKmerne8Z51qnsx+RNe1ogQ/NChOsoVQspclN mf6w== MIME-Version: 1.0 X-Received: by 10.50.180.200 with SMTP id dq8mr4723667igc.27.1358450888242; Thu, 17 Jan 2013 11:28:08 -0800 (PST) Received: by 10.64.135.39 with HTTP; Thu, 17 Jan 2013 11:28:08 -0800 (PST) In-Reply-To: References: Date: Thu, 17 Jan 2013 14:28:08 -0500 Message-ID: From: Dave Taht To: Maciej Soltysiak Content-Type: multipart/alternative; boundary=14dae9340671a376e904d380fe94 Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] Cerowrt 3.7.2-4 released, multicast (PIM and IGMP) fixed, kernel matches 3.3.8 again 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 Jan 2013 19:28:09 -0000 --14dae9340671a376e904d380fe94 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jan 17, 2013 at 2:10 PM, Maciej Soltysiak wro= te: > On Thu, Jan 17, 2013 at 2:41 PM, Dave Taht wrote: > >> It turned out the igmp entries in /proc ARE being stripped out by a >> openwrt patch... which I killed... so I built it again.... >> > What was the purpose of the patch, do you know? > A somewhat misguided attempt at "saving space" > > >> Hopefully this will resolve the dlna issue and others. > > It does, my wired TV and my wireless client work without a single change > of config! > YEA! > > However I got hit by the DNS / polipo bug with things like: > Jan 17 18:41:43 OpenWrt user.err polipo[2765]: Host mail.soltysiak.comloo= kup failed: Timeout (131072). > Jan 17 18:41:43 OpenWrt user.info sysinit: Host mail.soltysiak.com lookup > failed: Timeout (131072). > Jan 17 18:41:44 OpenWrt user.err polipo[2765]: Host notify5.dropbox.comlo= okup failed: Timeout (131072). > Jan 17 18:41:44 OpenWrt user.info sysinit: Host notify5.dropbox.comlookup= failed: Timeout (131072). > Jan 17 18:43:27 OpenWrt user.err polipo[2765]: Host notify5.dropbox.comlo= okup failed: Timeout (131072). > Jan 17 18:43:27 OpenWrt user.info sysinit: Host notify5.dropbox.comlookup= failed: Timeout (131072). > Funny is that I didn't see them with 3.7.1-1. > As I keep noting, it seems to take time to occur. Try usednsgethostbyname = =3D true for a while. (can't remember the capitalization) I'd love to nail this bug one one day because proxies really help on wifi in particular.... but next up on my todo list this week is nailing the last few traps and then thoroughly exercising ipv6. (in addition to a bunch of ns2 based sim work, which is actually my primary task) Some full packet captures from localhost when it starts failing would be useful. Also try it talking to localhost via ::1. > >> BTW: >> >> I had a little fun with uftp and uftpd with this (which are capable >> of thoroughly exercising multicast and igmp) >> >> http://www.tcnj.edu/~bush/uftp.html >> >> Basically setting up a uftpd client on a couple of machines and >> initiating uftp from the router, or vice versa, I was able to transfer >> multiple files around at the same time to multiple machines >> over wifi and wired. >> >> I've long yearned to have time to truly benchmark multicast >> at scale, and that's why uftp has been in there so long... >> >> To setup uftpd on cero (the file receiving deamon) >> >> uftpd -I se00,sw00,sw10,gw00,gw10 -D /tmp # or somewhere >> > uftp and uftpd don't seem to be in cero repository. > downloads.openwrt.org/snapshot/trunk/... has version 3.6.1, the latest > version is 3.7.1; the best thing would be to update upstream openwrt. > It's there. opkg update opkg install uftpd uftp I uypdated my version to 3.7.1, will push the patches out to openwrt as soon as I get a few more cleanups. > >> To send a file from somewhere to a listening uftpd >> >> uftp -I the_interface thefile >> > To be super weird, I used a 3.7.1 win32 client and 3.6.1 openwrt > daemon. speed I got wasn't very high, example: > > D:\TEMP>uftp DSC00160.JPG > UFTP version 3.7.1 Copyright (C) 2001-2012 Dennis A. Bush > Starting at Thu Jan 17 20:06:33 2013 > Transfer rate: 1000 Kbps (125 KB/s) > Wait between packets: 11718 us > Using private multicast address 230.5.5.59 Group ID: 033D43BF > Initializing group > Sending ANNOUNCE 1 > Received REGISTER from client 172.30.42.97 > Received REGISTER+ from client 172.30.42.97 > Sending REG_CONF 2.1 > Sending ANNOUNCE 2 > ----- DSC00160.JPG ----- > File ID: 0001 Name: DSC00160.JPG > sending as: DSC00160.JPG > Bytes: 869125 Blocks: 602 Sections: 1 > Sending FILEINFO 1.1 > Received INFO_ACK from client 172.30.42.97 > Maximum file transfer time: 20 seconds > Sending file...pass 1 > Sending DONE 1.1 > Got COMPLETE from client 172.30.42.97 > Average wait time =3D 11738.89 us > Received 0 distinct NAKs for pass 1 > Transfer status: > Host: 172.30.42.97 Status: Completed time: 7.082 seconds NAKs:= 0 > Total elapsed time: 7.082 seconds > Overall throughput: 119.84 KB/s > ----------------------------- > Finishing group > Sending DONE 1.1 > Got COMPLETE from client 172.30.42.97 > Late completions: > Sending DONE_CONF 2.1 > Group complete > uftp: Finishing at Thu Jan 17 20:06:56 2013 > Regards, > Maciej > > uftp is a VERY interesting protocol. For starters it defaults to a very low rate, which you can change, which is what I think you just saw here. If you aren't getting NAKs you aren't saturating your network. Try a gigabit. :) if you want to blow up your wifi, feel free to set it high. I have high hopes that fq_codel will still do something of the right thing with it, but as multicast packets have a high "weight", am not particularly hopeful. Need to script a test or three with it, now that it works. Secondly, it has a user configurable congestion control algorithm which is also very interesting, and yet very primitive. Thirdly, it can multicast encrypted it's content. That's a pretty unique facility. The web page describes its primary use case (distributing articles over satellite), I have a ton of others: 1) Keeping core files in sync across a network (think dns) 2) generating varying loads to route across wired and wifi with the uftp-proxy to test stuff with 3) blowing up igmp on bridges and elsewhere 4) sharing dns caches 5) co-existing with ccnx 6) video content (well, this is better done via vlc) 7) synchronized distributed audio content (linux's sound daemons can do this) I always liked multicast's promise, going back 2 decades now. I'll try not to fool with it too much, but I have to admit it can be like wet paint once you get it working right. --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html --14dae9340671a376e904d380fe94 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jan 17, 2013 at 2:10 PM, Maciej = Soltysiak <maciej@soltysiak.com> wrote:
On Thu, Jan 17, 2013 at 2:41 P= M, Dave Taht <dave.taht@gmail.com> wrote:
It turned out the igmp entries in /proc ARE being=A0 stripped out by a
openwrt patch... which I killed... so I built it again....
=
What was the purpose of the patch, do you=A0know?=A0
=

A somewhat misguided attempt at "saving space&qu= ot;
=A0
=A0
Hopefully this will resolve the dlna issue and others.
It does, my wired TV and my wireless client work without a=A0single chan= ge of config!

YEA!
=A0

However I got hit by the DN= S / polipo bug with things like:
Jan 17 18:41:43 OpenWrt user.err polipo[2765]: Host mail.soltysiak.com lookup failed:= Timeout (131072).
Jan 17 18:41:43 OpenWrt user.info sysinit: Host mail.soltysiak.com lookup failed: Timeout (1= 31072).
Jan 17 18:41:44 OpenWrt user.err polipo[2765]: Host notify5.dropbox.com lookup failed: Ti= meout (131072).
Jan 17 18:41:44 OpenWrt user.info sysinit: Host notify5.dropbox.com lookup failed: Timeout (13= 1072).
Jan 17 18:43:27 OpenWrt user.err polipo[2765]: Host notify5.dropbox.com lookup failed: Ti= meout (131072).
Jan 17 18:43:27 OpenWrt user.info sysinit: Host notify5.dropbox.com lookup failed: Timeout (13= 1072).
Funny is that I didn't see them with 3.7.1-1.

As I keep noting, it = seems to take time to occur. Try usednsgethostbyname =3D true for a while. = (can't remember the capitalization)

I'd love to nail this bug one one day because proxies really help o= n wifi in particular.... but next up on my todo list this week
is nailin= g the last few traps and then thoroughly exercising ipv6. (in addition to a= bunch of ns2 based sim work,
which is actually my primary task)
=A0
Some full packet captures from= localhost when it starts failing would be useful. Also try it talking to l= ocalhost via ::1.

=A0

BTW:

I had a little fun with uftp and uftpd with this (which are = capable
of thoroughly exercising multicast and igmp)

http://www.tcnj.edu/~bush/uftp= .html

Basically setting up a uftpd client on a couple of machine= s and
initiating uftp from the router, or vice versa, I was able to transfer
multiple files around at the same time to multiple machines
over wifi an= d wired.

I've long yearned to have time to truly benchmark multi= cast
at scale, and that's why uftp has been in there so long...

To setup uftpd on cero (the file receiving deamon)

uftpd -I se00= ,sw00,sw10,gw00,gw10 -D /tmp # or somewhere

uftp= and uftpd don't seem to be in cero repository.=A0downloads.openwrt.or= g/snapshot/trunk/... has version 3.6.1, the latest version is 3.7.1; th= e best thing would be to=A0update upstream=A0openwrt.

It's there.

opkg update
opkg inst= all uftpd uftp
=A0
I uypdated my version to 3.7.1, will push the patc= hes out to openwrt as soon as I get a few more cleanups.

=A0
To send a file from somewhere to a listening= uftpd

uftp -I the_interface thefile
To be super we= ird, I used a 3.7.1=A0win32 client and 3.6.1 openwrt daemon.=A0speed I got = wasn't very high, example:
=A0
D:\TEMP>uftp DSC0= 0160.JPG
UFTP version 3.7.1=A0 Copyright (C) 2001-2012=A0 Dennis A. Bush
Sta= rting at Thu Jan 17 20:06:33 2013
Transfer rate: 1000 Kbps (125 KB/s)Wait between packets: 11718 us
Using private multicast address 230.5.5.= 59=A0 Group ID: 033D43BF
Initializing group
Sending ANNOUNCE 1
Received REGISTER from client 1= 72.30.42.97
Received REGISTER+ from client 172.30.42.97
Sending REG_C= ONF 2.1
Sending ANNOUNCE 2
----- DSC00160.JPG -----
File ID: 0001= =A0 Name: DSC00160.JPG
=A0 sending as: DSC00160.JPG
Bytes: 869125=A0 Blocks: 602=A0 Sections: 1=
Sending FILEINFO 1.1
Received INFO_ACK from client 172.30.42.97
M= aximum file transfer time: 20 seconds
Sending file...pass 1
Sending D= ONE 1.1
Got COMPLETE from client 172.30.42.97
Average wait time =3D 11738.89 us<= br>Received 0 distinct NAKs for pass 1
Transfer status:
Host: 172.30.= 42.97=A0=A0=A0=A0 Status: Completed=A0=A0 time:=A0=A0 7.082 seconds=A0=A0= =A0 NAKs: 0
Total elapsed time: 7.082 seconds
Overall throughput: 119.84 KB/s
-----------------------------
Finishi= ng group
Sending DONE 1.1
Got COMPLETE from client 172.30.42.97
La= te completions:
Sending DONE_CONF 2.1
Group complete
uftp: Finishi= ng at Thu Jan 17 20:06:56 2013
Regards,
Maciej
=A0

uftp is a VERY interesting protocol. For starters it= defaults to a very low rate, which you can change,
which is what I thin= k you just saw here. If you aren't getting NAKs you aren't saturati= ng your network.
Try a gigabit. :)

if you want to blow up your wifi, feel free to set= it high. I have high hopes that fq_codel will
still do something of th= e right thing with it, but as multicast packets have a high "weight&qu= ot;,
am not particularly hopeful. Need to script a test or three with it, now th= at it works.

Secondly, it has a user configurable congestion control= algorithm which is also very interesting,
and yet very primitive.

Thirdly, it can multicast encrypted it's content. That's a pret= ty unique facility.

The web page describes its primary use case (dis= tributing articles over satellite), I have a ton of
others:

1) Ke= eping core files in sync across a network (think dns)
2) generating varying loads to route across wired and wifi with the uftp-pr= oxy
to test stuff with
3) blowing up igmp on bridges and elsewhere4) sharing dns caches
5) co-existing with ccnx
6) video content (wel= l, this is better done via vlc)
7) synchronized distributed audio content (linux's sound daemons can do= this)

I always liked multicast's promise, going b= ack 2 decades now. I'll try not to fool with it too much,
but I have= to admit it can be like wet paint once you get it working right.

--
Dave T=E4ht

Fixing bufferbloat with cerowrt: http://www= .teklibre.com/cerowrt/subscribe.html=20 --14dae9340671a376e904d380fe94--