From: Rick Jones <rick.jones2@hp•com>
To: Eric Dumazet <eric.dumazet@gmail•com>
Cc: "David S. Miller" <davem@davemloft•net>,
Linux Netdev List <netdev@vger•kernel.org>
Subject: Re: [RFC net-next-2.6] net: speedup sk_wake_async()
Date: Wed, 07 Oct 2009 08:53:37 -0700 [thread overview]
Message-ID: <4ACCB981.9030002@hp.com> (raw)
In-Reply-To: <4ACC0CDE.1020907@gmail.com>
Eric Dumazet wrote:
> Rick Jones a écrit :
>
>>How about 64-bit?
>
>
> No data yet, but larger footprint unfortunatly :-(
True - nothing comes for free. I'm not "in touch" with the embedded side, where
I presume 32 bit will be if not already is now the primary bitness, but over in
the server side of the world, at least the part I see, 64 bit is de rigeur,
hence my curiousity.
>>Got any netperf service demand changes?
>
>
> I was going to setup a bench lab, with a typical RTP mediaserver, with say
> 4000 UDP sockets, 2000 sockets exchanging 50 G.711 Alaw/ulaw
> messages per second tx and rx. (Total : 100.000 packets per second each way)
>
> Is netperf able to simulate this workload ?
Touche :)
It would be, well, cumbersome with netperf2, but possible. One would
./configure --enable-intervals and then run some variation of:
netperf -t UDP_STREAM -l <time> -H <remote> -b <burst size> -w <burst interval>
-- -m <message size>
a large number of times. Given the lack of test synchronization in netperf2 I
probably would not try to aggregate the results of N thousand simultaneous
netperf2 instances and would rely instead on external (relative to netperf)
packet rate reports.
Still, if the cache miss removed is a non-trivial fraction of the overhead I
would think that something like:
netperf -t UDP_RR -l <time> -I 99,0.5 -i 30,3 -c -C -H remote -- -r 4
run with and without the change would show a difference in the service demand,
and if you hit the confidence intervals you would be able, per the above be
confident in the "reality" of a CPU utilization difference of +/- 0.25% .
Getting that test to that level of confidence probably means pinning the NIC
interrupts to a specific CPU and then binding netperf/netserver on either side
using the global -T option.
Barring getting sutiable confidence intervals, somewhere in the middle of all
that would be ./configure --enable-burst and then, still with pinning and
binding for "stability" something like:
netperf -t UDP_RR -l <time> -I 99,0.5 -i 30,3 -H <remote> -- -r 4 -b <burst>
to put multiple transactions in flight across that flow - choosing <burst> to
take the CPU on which either netperf, netserver, or the interrupts are running
to 100% saturation. Here I left-off the CPU utilization since that is often the
thing that cannot hit the confidence intervals, and leave the aggregate
throughput as the proxy for efficiency change - which is why <burst> needs to
take something to saturation in each case.
happy benchmarking,
rick jones
prev parent reply other threads:[~2009-10-07 15:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-06 23:08 [RFC net-next-2.6] net: speedup sk_wake_async() Eric Dumazet
2009-10-07 0:28 ` David Miller
2009-10-07 0:42 ` Rick Jones
2009-10-07 3:37 ` Eric Dumazet
2009-10-07 4:43 ` [PATCH] udp: extend hash tables to 256 slots Eric Dumazet
2009-10-07 5:29 ` David Miller
2009-10-07 5:33 ` Eric Dumazet
2009-10-07 5:35 ` David Miller
2009-10-07 10:37 ` [PATCH net-next-2.6] udp: dynamically size hash tables at boot time Eric Dumazet
2009-10-07 10:47 ` David Miller
2009-10-08 5:01 ` David Miller
2009-10-07 15:53 ` Rick Jones [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=4ACCB981.9030002@hp.com \
--to=rick.jones2@hp$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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