On Thu, Jul 28, 2016 at 03:01:36PM +0800, Xin Long wrote:
On Wed, Jul 27, 2016 at 9:54 AM, kernel test robot
> FYI, we noticed a -37.2% regression of netperf.Throughput_Mbps due to commit:
> commit a6c2f792873aff332a4689717c3cd6104f46684c ("sctp: implement prsctp TTL
> in testcase: netperf
> on test machine: 4 threads Ivy Bridge with 8G memory
> with following parameters:
> ip: ipv4
> runtime: 300s
> nr_threads: 200%
> cluster: cs-localhost
> send_size: 10K
> test: SCTP_STREAM_MANY
> cpufreq_governor: performance
> Results have been estimated based on internal Intel analysis and are provided
> for informational purposes only. Any difference in system hardware or software
> design or configuration may affect actual performance.
It doesn't make much sense to me. the codes I added cannot be
triggered without enable any pr policies. and I also did the tests in
It seems these pr policies has to be turned on by user space, i.e.
netperf in this case?
I checked netperf's source code, it doesn't seem set any option
related to SCTP PR POLICY but I'm new to network code so I could be
wrong or missing something.
my local environment, the result looks normal to me compare to
Can you share your number?
We run netperf like this:
netperf -4 -t SCTP_STREAM_MANY -c -C -l 300 -- -m 10K -H 127.0.0.1
The full log of the run is attached for your reference.
Recently the sctp performance is not stable, as during these patches,
netperf cannot get the result, but return ENOTCONN. which may
also affect the testing. anyway we've fixed the -ENOTCONN issue
already in the latest version.
I tested commit 96b585267f55, which is Linus' git tree HEAD on 08/03, I
guess the fix you mentioned should already be in there? But
unfortunately, the throughput of netperf is still at low number(we did
the test 5 times):
$ cat */netperf.json
Considering what you have said that the patch shouldn't make a
difference, the performance drop is really confusing. Any idea what
could be the cause? Thanks.