From: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
To: The list for a Better Approach To Mobile Ad-hoc Networking
<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] Unused structs in Catwoman packet buffers
Date: Mon, 17 Oct 2011 20:19:20 +0200 [thread overview]
Message-ID: <20111017181920.GA15303@pandem0nium> (raw)
In-Reply-To: <20111017163754.GA1646@ritirata.org>
[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]
Hey Martin,
just my two cents: I agree to Antonio to keep the packet list struct alive at least
for a few seconds. If your packet stream has less than 100 packets per second
(which is quite common IMHO) for your 10ms send-and-free scenario, many packet list
structs would be destroyed and reinitialized over the time.In worst case,
this would happen for every single packet which comes by, for example if you have a
steady 50 packets/s stream (typical VoIP streams with 20ms packetization).
Cheers
Simon
On Mon, Oct 17, 2011 at 06:37:55PM +0200, Antonio Quartulli wrote:
> Hello Martin,
>
> and thank you for the explanation.
>
> On Mon, Oct 17, 2011 at 03:16:25 +0200, Martin Hundebøll wrote:
> > Now here's the question:
> > When a list of a certain coding_path becomes empty, should I free the coding_path right away, or should I timestamp it and mark it for removal at a later time. The thing is that I don't know whether a new packet for the same coding_path will arrive in a short moment. If I have just freed the coding_path struct, I would have to spend ressources to initialize it again...
> >
> > It is probably a micro-optimiziation and the simplest solution would be to just free it right away, but I would like to have your comments anyways.
>
> In my opinion it would be better to _keep_ the struct even if the corresponding
> packet list is empty.
>
> Imagine there are two packet flows going through a relay
> node R. If the two coding paths of the two flows have an high coding correlation
> at R (coding opportunity?), one of the two packet lists on R will be emptied
> several times during the data transmission.
>
> For this reason I think it would be better to wait a fixed time before freeing
> such structure. The overhead given by the freeing/reallocating/reinitialising
> operation could become not negligible.
>
> I hope that I correctly understood the problem and that my idea was clear :-)
>
> Cheers,
>
>
> --
> Antonio Quartulli
>
> ..each of us alone is worth nothing..
> Ernesto "Che" Guevara
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
prev parent reply other threads:[~2011-10-17 18:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-17 13:16 [B.A.T.M.A.N.] Unused structs in Catwoman packet buffers Martin Hundebøll
2011-10-17 16:37 ` Antonio Quartulli
2011-10-17 17:34 ` Martin Hundebøll
2011-10-17 18:19 ` Simon Wunderlich [this message]
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=20111017181920.GA15303@pandem0nium \
--to=simon.wunderlich@s2003.tu-chemnitz.de \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
/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