From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp121.iad.emailsrvr.com (smtp121.iad.emailsrvr.com [207.97.245.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id F271B200957 for ; Sat, 16 Jun 2012 05:54:19 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp32.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 774101485E5; Sat, 16 Jun 2012 08:54:03 -0400 (EDT) X-Virus-Scanned: OK Received: from legacy19.wa-web.iad1a (legacy19.wa-web.iad1a.rsapps.net [192.168.2.205]) by smtp32.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 5591B14818A; Sat, 16 Jun 2012 08:54:03 -0400 (EDT) Received: from reed.com (localhost.localdomain [127.0.0.1]) by legacy19.wa-web.iad1a (Postfix) with ESMTP id 382492D5806B; Sat, 16 Jun 2012 08:54:03 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Sat, 16 Jun 2012 08:54:03 -0400 (EDT) Date: Sat, 16 Jun 2012 08:54:03 -0400 (EDT) From: dpreed@reed.com To: "Alexander Hulse" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20120616085403000000_95191" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: Message-ID: <1339851243.228313596@apps.rackspace.com> X-Mailer: webmail7.0 Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] =?utf-8?q?Baby_jumbo_frames_support=3F?= 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: Sat, 16 Jun 2012 12:54:26 -0000 ------=_20120616085403000000_95191 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0ADigging deeper, there is also a good reason for bigger frames when one i= s using 600 Mbit 802.11 signalling ( that's 75 bytes per microsecond). A 1= 500 byte frame occupies only 50 microseconds of airtime. Not much return fo= r the investment in contention time (5-10 microseconds) by the transmitting= station. 9000 byte frames would be good, just as they are for GigE.=0A = =0A-----Original Message-----=0AFrom: "Alexander Hulse" =0ASen= t: Saturday, June 16, 2012 5:53am=0ATo: cerowrt-devel@lists.bufferbloat.net= =0ASubject: [Cerowrt-devel] Baby jumbo frames support?=0A=0A=0A=0AI've done= some basic research and some (unsuccessful) hacking the on the driver sour= ce for the ag71xx driver and was wondering about baby jumbo frame support?= =0A=0AI know that the WNDR37/800's built in switch supports passing jumbo f= rames, but the underlying router interfaces do not support large MTU frames= .=0A=0AHowever, this:=0A=0Ahttp://wiki.mikrotik.com/wiki/Manual:Maximum_Tra= nsmission_Unit_on_RouterBoards=0A=0Aseems to imply that the built-in interf= aces ought to support baby jumbo frames, unless I'm misunderstanding what t= hey are saying.=0A=0AAs 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 described in RFC 4638.=0A=0AIt was possible using a Netgear WNR83= 4T with the application of some patches from the pppd git:=0A=0Ahttp://git.= ozlabs.org/?p=3Dppp.git;a=3Dcommit;h=3Dfd1dcdf758418f040da3ed801ab001b5e468= 54e7=0Ahttp://wiki.aa.net.uk/index.php/FTTC_Modem=0A=0AWould this be a usef= ul feature to add (if possible) to CeroWrt so that full sized frames can be= used if the ISP / connection supports it?=0A=0AAlex=0A____________________= ___________________________=0ACerowrt-devel mailing list=0ACerowrt-devel@li= sts.bufferbloat.net=0Ahttps://lists.bufferbloat.net/listinfo/cerowrt-devel ------=_20120616085403000000_95191 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Digging de= eper, there is also a good reason for bigger frames when one is using 600 M= bit 802.11 signalling ( that's 75 bytes per microsecond).  A 1500 byte= frame occupies only 50 microseconds of airtime. Not much return for the in= vestment in contention time (5-10 microseconds) by the transmitting station= .  9000 byte frames would be good, just as they are for GigE.

=0A 

=0A

-----Original Message-----
From: "Alexander Hulse" <ah@amch.net&g= t;
Sent: Saturday, June 16, 2012 5:53am
To: cerowrt-devel@lists.b= ufferbloat.net
Subject: [Cerowrt-devel] Baby jumbo frames support?

=0A
=0A

I've done some basic research and some (unsuccessful) hacking the = on the driver source for the ag71xx driver and was wondering about baby jum= bo frame support?

I know that the WNDR37/800's built in switch s= upports passing jumbo frames, but the underlying router interfaces do not s= upport large MTU frames.

However, this:

http://wiki.m= ikrotik.com/wiki/Manual:Maximum_Transmission_Unit_on_RouterBoards

seems to imply that the built-in interfaces ought to support baby jumbo f= rames, unless I'm misunderstanding what they are saying.

As to t= he "Why?", in the UK, the fibre offering by BT using FTTC uses a PPPoE mode= m that can understand PPPoE packets with an MTU 1508, as described in RFC 4= 638.

It was possible using a Netgear WNR834T with the applicatio= n of some patches from the pppd git:

http://git.ozlabs.org/?p=3D= ppp.git;a=3Dcommit;h=3Dfd1dcdf758418f040da3ed801ab001b5e46854e7
http:/= /wiki.aa.net.uk/index.php/FTTC_Modem

Would this be a useful feat= ure to add (if possible) to CeroWrt so that full sized frames can be used i= f the ISP / connection supports it?

Alex
__________________= _____________________________
Cerowrt-devel mailing list
Cerowrt-= devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cer= owrt-devel

=0A
 ------=_20120616085403000000_95191--