[netperf-talk] cpu utilization on solaris

[Rick Jones]

While looking at the src/nettest_omni.c code in preparation for migrating some 
of the "classic" netperf tests to use the "two routines to measure it all" code 
in nettest_omni.c I am reminded that the UDP_RR test is controlled by time and 
the timer on the remote runs for an extra PAD_TIME seconds.  That is to make 
certain the netserver doesn't end the test before netperf does.  The CPU 
utilization code knows about this and in keeping with the ass-u-me-ption that 
there is only really one netperf/netserver running will adjust the CPU 
utilization accordingly.  It is possible that, in conjunction with running 
multiple, concurrent UDP_RR tests is affecting the "accuracy" :) of the CPU 
utilization calculation.

If that is indeed the case, I would expect that longer run times would result in 
remote CPU utilizations getting closer to 100% as PAD_TIME (4 seconds, IIRC) 
becomes a smaller and smaller fraction of the run time.

The TCP_RR test, since it has the "positive indication of test end on the data 
connection" (ie the read return of zero) does not have the PAD_TIME issue.

In the omni tests I go back to something I rejected "way back when" but is used 
in other benchmarks - to let the UDP test(s) exit at the far end without waiting 
for the timer+PAD_TIME to pass, the netperf omni test will send three 
zero-length UDP datagrams on the data connection.  The idea is that at least one 
of those will get through and cause a "read return of zero" to get the netserver 
side out of its loop.  The timer is still there on the remote "just in case" so 
there could still be that issue if the three zero-length datagrams were all dropped.

So, it might be interesting to try aggregate "omni" tests set for UDP_RR 
behaviour in addtion to trying the longer run times with the "classic" tests.

happy benchmarking,

rick jones