2015-11-16 19:46 GMT+01:00 Jan Tluka jtluka@redhat.com:
*** WARNING: THE ATTACHED DOCUMENT(S) CONTAIN MACROS *** *** MACROS MAY CONTAIN MALICIOUS CODE *** *** Open only if you can verify and trust the sender *** *** Please contact infosec@redhat.com if you have questions or concerns **
Mon, Nov 16, 2015 at 07:41:07PM CET, jtluka@redhat.com wrote:
Thu, Nov 12, 2015 at 02:47:16PM CET, jtluka@redhat.com wrote:
Thu, Nov 12, 2015 at 12:19:53PM CET, olichtne@redhat.com wrote:
On Wed, Nov 11, 2015 at 02:55:11PM +0100, Jiri Prochazka wrote:
This patch adds support for measuring both local and remote CPU
utilization:
New option for netperf client have been added: cpu_util - when set to "local", netperf is run with -c argument,
enabling measure of local CPU utilization during run,
when set to "remote", netperf is run with -C argument,enabling measure of remote CPU utilization during run,
when set to "both", netperf is run with both -c and -Carguments
Parsing of throughput and confidence interval has been made cleaner: Using omni netperf output, all relevant data are now stored in
key=val format,
which can be parsed more easily and is the same for all netperftest types.
Changes in v2: Changed format of cpu_util argument (described above)
Renamed keys in res_val dict to from loc_cpu_util and rem_cpu util to LOCAL_CPU_UTIL and REMOTE_CPU_UTIL
Fixed incorrect real confidence value, now the touple correctly returns (CONFIDENCE_LEVEL, THROUGHPUT_CONFIDENCE_INTERVAL/2)
Changes in v3: Removed redundant error value parsing from _parse_confidence method
Signed-off-by: Jiri Prochazka jprochaz@redhat.com
Looks good, after jtlukas tests finish and there's no new problems i'll ack and push it.
Tests are ok. I've checked whether confidence is same with old and new approach and it's the same.
Acked-by: Jan Tluka jtluka@redhat.com
I've noticed that the UDP_STREAM performance dropped after this change. First I thought it is because of cpu utilization data collection but disabling this did not help.
Very likely this is because of OMNI output. I've looked in the netperf code and there are few other "THROUGHPUT" values:
src/nettest_omni.c:
LOCAL_SEND_THROUGHPUT, LOCAL_RECV_THROUGHPUT, REMOTE_SEND_THROUGHPUT, REMOTE_RECV_THROUGHPUT,
I'm wondering if the previous value that we reported is some of these.
See this: http://pastebin.com/5hFYVUtH%E2%80%8B
The THROUGHPUT value is the same as REMOTE_RECV_THROUGHPUT which in my opinion what we want to measure. If I remember correcly, before this patch we measured throughput on remote receive as well, how big is the performance drop, you are talking about?
LNST-developers mailing list lnst-developers@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/lnst-developers@lists.fedorahoste...
Cut from netperf code:
nettest_omni.c send_omni_innner()
remote_bytes_received =(uint64_t)omni_result->bytes_received_hi << 32; remote_bytes_received += omni_result->bytes_received_lo; remote_bytes_xferd = (double) remote_bytes_received + remote_bytes_sent;
if ('x' == libfmt) /* it was a request/responsetest */ thruput = calc_thruput((double)trans_completed); else if (NETPERF_RECV_ONLY(direction)) thruput = calc_thruput(bytes_xferd); else thruput = calc_thruput(remote_bytes_xferd);
local_send_thruput =calc_thruput((double)bytes_sent); local_recv_thruput = calc_thruput((double)bytes_received); remote_send_thruput = calc_thruput((double)remote_bytes_sent); remote_recv_thruput = calc_thruput((double)remote_bytes_received);
nettest_unix.c
local_thruput = calc_thruput(bytes_sent); ... messages_recvd = dg_stream_results->messages_recvd; bytes_recvd = send_size * messages_recvd; remote_thruput = calc_thruput(bytes_recvd); _______________________________________________ LNST-developers mailing list lnst-developers@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/lnst-developers@lists.fedorahoste...