Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
To: <cake@lists.bufferbloat.net>
Subject: [Cake] Ethernet frame overheads
Date: Wed, 30 Sep 2015 11:53:01 +0100	[thread overview]
Message-ID: <560BBF0D.2080802@darbyshire-bryant.me.uk> (raw)

[-- Attachment #1: Type: text/plain, Size: 1329 bytes --]

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


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]

             reply	other threads:[~2015-09-30 10:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-30 10:53 Kevin Darbyshire-Bryant [this message]
2015-09-30 12:11 ` Sebastian Moeller
2015-09-30 12:36 ` Benjamin Cronce

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=560BBF0D.2080802@darbyshire-bryant.me.uk \
    --to=kevin@darbyshire-bryant.me.uk \
    --cc=cake@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox