From: Peter Kietzmann <peter.kietzmann@haw-hamburg.de>
Cc: linux-wpan@vger.kernel.org
Subject: Re: UDP stress-testing
Date: Fri, 8 Apr 2016 09:22:29 +0200 [thread overview]
Message-ID: <57075C35.5070206@haw-hamburg.de> (raw)
In-Reply-To: <20160407204125.GA4736@omega>
Hi Alex,
thanks for your quick reply. It helped a lot! See some comments inline.
Am 07.04.2016 um 22:41 schrieb Alexander Aring:
> On Thu, Apr 07, 2016 at 10:19:35PM +0200, Peter Kietzmann wrote:
>> Dear list,
>>
>> first of all let me say that I'm new to this list. So if I'm completely
>> wrong in my concern please excuse the noise and guide me to the right place.
>> If you can :-)!
>>
>> For some experiments I'm trying to send "great" numbers of UDP packets with
>> "great" payloads as fast as possible from a RasPi equipped with the Openlabs
>> transceiver. With another RasPi+transceiver I'm sniffing the traffic. It
>> turns out that just the first x packets are sent out correctly before the
>> outgoing packets come out irregularly. The number of correctly sent packets
>> depends on the UDP payload size and it looks like the problem occurs after
>> ~30-35 kB Bytes (gross) in total have been transmitted (fragmentation
>> overhead included). I already increased the send socket memory to a
>> reasonably high value, without success. But still I assume some buffer
>> problems. Do you have a hint which screw to adjust?
>>
>> BTW: Introducing a delay after each packet to send fixes the problem. But
>> I'd like to do stress-testing...
>
> 1.
>
> You cannot be sure that a monitor interface shows all traffic which is
> on the air. You have at least hardware limitations which begins at
> "rising IRQ" and ends at "framebuffer readed".
I totally agree. But here it was quite obvious something was going on
after some time.
>
> 2.
>
> Try to enable ack request bit. This is default disabled because you need
> to know what you doing when you enable it. Be sure all nodes supports
> ACK handling before that.
>
> You can do that with:
>
> iwpan dev $WPAN_DEV set ackreq_default 1
Found out that my sender Pi doesn't support this option. Guess I should
update it...
>
> 3.
>
> Change tx queue setting:
>
> ip link set txqueuelen 1000 dev $WPAN_DEV
That was the parameter I was looking for. Increasing this queue it is :-) !
>
>
>
> Please reply if that helped you otherwise we will maybe find another
> tweaks. :-)
>
> - Alex
>
Again, thanks for your quick help!
Cheers
Peter
--
Peter Kietzmann
Hamburg University of Applied Sciences
Dept. Informatik, Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: +49-40-42875-8426
Web: http://www.haw-hamburg.de/inet
next prev parent reply other threads:[~2016-04-08 7:22 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 [this message]
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
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=57075C35.5070206@haw-hamburg.de \
--to=peter.kietzmann@haw-hamburg.de \
--cc=linux-wpan@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).