From: Michael Richardson <mcr@sandelman.ca>
To: Alexander Aring <alex.aring@gmail.com>
Cc: linux-wpan@vger.kernel.org,
Peter Kietzmann <peter.kietzmann@haw-hamburg.de>
Subject: Re: UDP stress-testing
Date: Wed, 13 Apr 2016 08:50:22 -0400 [thread overview]
Message-ID: <16058.1460551822@obiwan.sandelman.ca> (raw)
In-Reply-To: <20160413082852.GA2428@omega>
[-- Attachment #1: Type: text/plain, Size: 1608 bytes --]
Alexander Aring <alex.aring@gmail.com> wrote:
> _All_ current supported transceivers have on hardware side _one_
> framebuffer only.
> I would agree 3-4 frames should keep the transmitter buffer, because
> only one framebuffer, 250kBit (even slower on sub 1-GHz) and holding
> 3-4 skb's in background.
If we are counting frames rather than packets, then I agree that 3-4 is too
low; we should accomodate 2-3 full-sized IPv6 packets worth of fragments.
1280 / 88 = 14 * 3 = 42.
So I suggest somewhere between 32 and 48 as a good default.
Well, we really ought to use the BQL to get the right number!
https://lwn.net/Articles/469652/
> On most systems the qdisc default is pfifo (but I remember something
> that systemd changed to fq_codel as default).
yes, fq_codel is often the default now.
> This will getting the queue full and with payload of 352 bytes it makes
> fragments invalid because pfifo will drop some which is part of the
> whole fragment.
I had assumed that the fragmentation happened after the qdisc.
> What I know is, when we drop one fragment, then we could drop every
> fragment inside the queue which comes from the whole fragmented 6lowpan
> packet. it seems this will not be handled currently.
This is very important, and why I had assumed that fragmentation was
afterwards.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 464 bytes --]
next prev parent reply other threads:[~2016-04-13 12:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-07 20:19 UDP stress-testing Peter Kietzmann
2016-04-07 20:41 ` Alexander Aring
2016-04-08 7:22 ` Peter Kietzmann
2016-04-08 12:58 ` Alexander Aring
2016-04-13 0:00 ` Michael Richardson
2016-04-13 8:28 ` Alexander Aring
2016-04-13 12:50 ` Michael Richardson [this message]
2016-04-13 20:34 ` Alexander Aring
2016-04-14 8:53 ` Peter Kietzmann
2016-04-14 14:59 ` Alexander Aring
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=16058.1460551822@obiwan.sandelman.ca \
--to=mcr@sandelman.ca \
--cc=alex.aring@gmail.com \
--cc=linux-wpan@vger.kernel.org \
--cc=peter.kietzmann@haw-hamburg.de \
/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