From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.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 C363621F0C9 for ; Wed, 20 Jun 2012 17:50:32 -0700 (PDT) Received: by lbom4 with SMTP id m4so3038101lbo.16 for ; Wed, 20 Jun 2012 17:50:30 -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=feaFNV9bn4yigvLHT9opVARaOv8VtKwHzar3DqocQHE=; b=m6BTHlMvFdeCnPWXjKCSq+U3am74F3i+qgRFwYRrd0MbLI/etovtFfHKI770tzkPPy ++wYxt+MxZigkx8E4HJMSF2ICA5tUExTteTBDGzMzGH1//W8pcltWF5jkMvMvR+bR3Qm sjihlN8gQ6t/v1shD/KY0+RLS94DgaNTsln8k47tC70/jRDgY9AA/n0ahfzf0dgFo6HO 8hm431XYg3ZOXlnYpgREApueQDIgFDtp52F4T2d7iOjB/PlMRrse4j3xfTTlRpyCcLS8 34lYNcdgcWLtcA5MOYsEzsqqB5QK1GmhlWXU1a7S9OAnwKP2SqqBeRZkQoQeiWPbfuBp 0tEw== MIME-Version: 1.0 Received: by 10.152.102.137 with SMTP id fo9mr24653096lab.35.1340239829835; Wed, 20 Jun 2012 17:50:29 -0700 (PDT) Received: by 10.112.85.71 with HTTP; Wed, 20 Jun 2012 17:50:29 -0700 (PDT) In-Reply-To: <1339851243.228313596@apps.rackspace.com> References: <1339851243.228313596@apps.rackspace.com> Date: Wed, 20 Jun 2012 20:50:29 -0400 Message-ID: From: Dave Taht To: dpreed@reed.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: cerowrt-devel@lists.bufferbloat.net, Felix Fietkau Subject: Re: [Cerowrt-devel] Baby jumbo frames support? 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, 21 Jun 2012 00:50:33 -0000 I'd kind of hoped someone other than me would answer this because the details are long and intricate. Another way to put it is that after hearing simon barber, myself, andrew mcgregor spend 5 hours trying to explain the issues of wireless-n to kathie nichols and jg and multiple other devs one day, a prominent networking developer in the room shook his head, and said "I'm glad I work on 10GigE. It's so much simpler". Bigger packet sizes are not necessary or useful in the current wifi standards because of packet aggregation which bundles up to 42 packets in one burst. There's this HUGE header, followed by X packets in an aggregated "A-MPDU". A-MPDU bursts =3D TSO/GSO on steroids, with similar (but worse) attendant side effects (big checksum and ack on portions or the whole bundle!), and dwarf classic (9k) jumbo packets in size - and don't require reframing when put on the internet. A-MSDU is a similar concept but proven thus far hard to implement. On my bad days I think the ratio between ack (68) and max packet (1500) MTU is too large, already. As for other wireless standards, say something high bandwidth for tvs, I could see short haul stuff taking advantage of larger frame sizes, but as for wifi, gprs, 3g,4g, no. Felix and I did a pair of podcasts on this stuff, one when we first met back in the early days of bufferbloat, and the second in august after we'd been working together for a while. The first half of the second is largely historical; it got detailed about 40+ minutes in. I think these are only useful now as historical documents but if enjoy this sort of background noise, certainly they were stepping stones towards mutual understanding for felix and I. http://mirrors.bufferbloat.net/podcasts/BPR-The_Wireless_Stack.mp3 http://huchra.bufferbloat.net/~d/talks/felix/ (includes a transcript) I ran out of budget for transcripts soon afterward. :( Anyway... As the wifi standards are backward compatible, the surrounding frame is broadcast at a rate that made sense in 1998 in many cases, so the time spent establishing a frame can far outweigh the actual data transfered. This is not a bad description of what happens in wireless-n, but dated. http://thenetworkguy.typepad.com/nau/2007/12/caveats-of-larg.html Kind of missed the infinite retry bugs endemic today... among others... Lastly Andrew McGregor has a wonderful and apparently unpublishable (far beyond the MPU) paper on how the minstrel rate selection algorithm works, rate selection and retry being the big thing that throws the fixed size/time/width calculation you use below overboard, documenting 1/3 a page of related variables in wireless. Perhaps he can send that over? I wish I'd recorded the 3 hours he spent with me explaining in detail how minstrel worked, it was these three indepth conversations and that paper that were the seed crystals of converting my obsolete-as-of-2006 understanding of wifi to where I stand now. I almost forgot to mention that 802.11e has 4 queues already, each with different algos for grabbing airtime - and an effectively invisible set of queues for managing frames and crypto... On Sat, Jun 16, 2012 at 8:54 AM, wrote: > Digging deeper, there is also a good reason for bigger frames when one is > using 600 Mbit 802.11 signalling ( that's 75 bytes per microsecond).=A0 A= 1500 > byte frame occupies only 50 microseconds of airtime. Not much return for = the > investment in contention time (5-10 microseconds) by the transmitting > station.=A0 9000 byte frames would be good, just as they are for GigE. > > > > -----Original Message----- > From: "Alexander Hulse" > Sent: Saturday, June 16, 2012 5:53am > To: cerowrt-devel@lists.bufferbloat.net > Subject: [Cerowrt-devel] Baby jumbo frames support? > > I've done some basic research and some (unsuccessful) hacking the on the > driver source for the ag71xx driver and was wondering about baby jumbo fr= ame > support? > > I know that the WNDR37/800's built in switch supports passing jumbo frame= s, > but the underlying router interfaces do not support large MTU frames. > > However, this: > > http://wiki.mikrotik.com/wiki/Manual:Maximum_Transmission_Unit_on_RouterB= oards > > seems to imply that the built-in interfaces ought to support baby jumbo > frames, unless I'm misunderstanding what they are saying. > > As to the "Why?", in the UK, the fibre offering by BT using FTTC uses a > PPPoE modem that can understand PPPoE packets with an MTU 1508, as descri= bed > in RFC 4638. > > It was possible using a Netgear WNR834T with the application of some patc= hes > from the pppd git: > > http://git.ozlabs.org/?p=3Dppp.git;a=3Dcommit;h=3Dfd1dcdf758418f040da3ed8= 01ab001b5e46854e7 > http://wiki.aa.net.uk/index.php/FTTC_Modem > > Would this be a useful feature to add (if possible) to CeroWrt so that fu= ll > sized frames can be used if the ISP / connection supports it? > > Alex > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > --=20 Dave T=E4ht http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-6 is out with fq_codel!"