From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::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 986F521F860 for ; Wed, 30 Sep 2015 05:36:12 -0700 (PDT) Received: by ykdt18 with SMTP id t18so39388798ykd.3 for ; Wed, 30 Sep 2015 05:36:11 -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; bh=utqTQgDtDmgzHLzrIM5QxUiYTPAQA6/UNDd4RT4L+3M=; b=iNrt0BdqT6zrp12wTLcLqSDR8jAspHHGb+Q3qsCdLADfKG+umwPVbNU1yZObqbi/e3 8cZ2DhP0tcvX+m2gCDTEc33vkF4AMFl1Rt36HCA8IKJdUzGmrSfEf8QZYQCL5kYjuDVR JmAMNIP18vwHkcaDNG2YkIx5MG0DETPWmYJkW9z0/4i7kZqTMI2vgdNRhLkqkbtBHVA7 KFo3QHXQmsG+FHAOmh6I7lxnT6KqHZUlU4uhqyOnjPOrkCcQ4Tijo5LP9Yej9/ATfHB6 yxsR3ePM1uu+guYzdNPR8Ur9k/67Vp3FIzRT7k+T2sPQCuxpUFsbaQemXX3k8LDe95wG DScQ== MIME-Version: 1.0 X-Received: by 10.129.76.71 with SMTP id z68mr2807118ywa.52.1443616571191; Wed, 30 Sep 2015 05:36:11 -0700 (PDT) Received: by 10.13.236.80 with HTTP; Wed, 30 Sep 2015 05:36:11 -0700 (PDT) In-Reply-To: <560BBF0D.2080802@darbyshire-bryant.me.uk> References: <560BBF0D.2080802@darbyshire-bryant.me.uk> Date: Wed, 30 Sep 2015 07:36:11 -0500 Message-ID: From: Benjamin Cronce To: Kevin Darbyshire-Bryant Content-Type: multipart/alternative; boundary=001a113f19f2eafb110520f62c86 Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] Ethernet frame overheads X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 12:36:34 -0000 --001a113f19f2eafb110520f62c86 Content-Type: text/plain; charset=UTF-8 I'm pretty sure Ethernet rates are at the Layer 2, so we only need to care about Layer 2 sizes, not Layer 1. At Layer 1, Ethernet is faster than the listed 10/100/1000/10000 rates. You are correct about worrying about VLAN, but I would hope they actually include these. On Wed, Sep 30, 2015 at 5:53 AM, Kevin Darbyshire-Bryant < kevin@darbyshire-bryant.me.uk> wrote: > Greetings fellow cake eaters :-) > > Sebastian raised a little flag in the brain cell yesterday in his > questioning/discussion of cake stats & kernel accounted for overheads. > As he stated the kernel considers the overhead of an ethernet packet to > be 14 bytes but forgets about the 4 byte frame check sequence and > pre/post ambles which in the end make a packet on the wire worth 1538 > bytes (must use octets, must use octets) > > Jonathan pointed out that cake's overhead parameter/s are used for > timing purposes, which to me makes it all the more important that > overheads are got right. > > As much as I'm loath to suggest yet another option to cake, should it > not by default assume ethernet 'on-the-wire' framing overheads > (preamble& start of frame=8, FCS=4, interpacket gap=12) totalling 24 > octets, not forgetting VLAN tag/s at 4 octets each and the already > accounted for 14 octets of MAC source,dest & frame type/length for > timing purposes? Ref: https://en.wikipedia.org/wiki/Ethernet_frame > > For ethernet links this is going to be important. For other links > 'transporting' ethernet at slower rates (I'm thinking VDSL2 modems & the > like) I suspect their overheads and pure slowness of link swamp the > timing discrepancy. > > 'ethernet' & 'ethernetotw' flags? > > What don't I understand properly here? > > Kevin > > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake > > --001a113f19f2eafb110520f62c86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm pretty sure Ethernet rates are at the Layer 2, so = we only need to care about Layer 2 sizes, not Layer 1. At Layer 1, Ethernet= is faster than the listed 10/100/1000/10000 rates. You are correct about w= orrying about VLAN, but I would hope they actually include these.

On Wed, Sep 30, 2015 = at 5:53 AM, Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.m= e.uk> wrote:
Greetings fell= ow cake eaters :-)

Sebastian raised a little flag in the brain cell yesterday in his
questioning/discussion of cake stats & kernel accounted for overheads.<= br> As he stated the kernel considers the overhead of an ethernet packet to
be 14 bytes but forgets about the 4 byte frame check sequence and
pre/post ambles which in the end make a packet on the wire worth 1538
bytes=C2=A0 (must use octets, must use octets)

Jonathan pointed out that cake's overhead parameter/s are used for
timing purposes, which to me makes it all the more important that
overheads are got right.

As much as I'm loath to suggest yet another option to cake, should it not by default assume ethernet 'on-the-wire' framing overheads
(preamble& start of frame=3D8, FCS=3D4, interpacket gap=3D12) totalling= 24
octets, not forgetting VLAN tag/s at 4 octets each and the already
accounted for 14 octets of MAC source,dest & frame type/length for
timing purposes?=C2=A0 Ref: https://en.wikipedia.org/wik= i/Ethernet_frame

For ethernet links this is going to be important.=C2=A0 For other links
'transporting' ethernet at slower rates (I'm thinking VDSL2 mod= ems & the
like) I suspect their overheads and pure slowness of link swamp the
timing discrepancy.

'ethernet' & 'ethernetotw' flags?

What don't I understand properly here?

Kevin


_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake


--001a113f19f2eafb110520f62c86--