Chapter 3: The Design of Netperf 9
power consumption, it has been suggested that this mechanism may become
slightly confused, in which case using BIOS/uEFI settings to disable the power
saving would be indicated.
S This mechanism uses ‘/proc/stat’ on Linux to retrieve time (ticks) spent in
idle mode. It is thought but not known to be reasonably accurate. The code
for this mechanism can be found in ‘src/netcpu_procstat.c’.
C A mechanism somewhat similar to S but using the sysctl() call on BSD-like
Operating systems (*BSD and MacOS X). The code for this mechanism can be
found in ‘src/netcpu_sysctl.c’.
Others Other mechanisms included in netperf in the past have included using the
times() and getrusage() calls. These calls are actually rather poorly suited to
the task of measuring CPU overhead for networking as they tend to be process-
specific and much network-related processing can happen outside the context
of a process, in places where it is not a given it will be charged to the correct, or
even a process. They are mentioned here as a warning to anyone seeing those
mechanisms used in other networking benchmarks. These mechanisms are not
available in netperf 2.4.0 and later.
For many platforms, the configure script will chose the best available CPU utilization
mechanism. However, some platforms have no particularly good mechanisms. On those
platforms, it is probably best to use the “LOOPER” mechanism which is basically some
number of processes (as many as there are processors) sitting in tight little loops counting
as fast as they can. The rate at which the loopers count when the system is believed to be
idle is compared with the rate when the system is running netperf and the ratio is used to
compute CPU utilization.
In the past, netperf included some mechanisms that only reported CPU time charged
to the calling process. Those mechanisms have been removed from netperf versions 2.4.0
and later because they are hopelessly inaccurate. Networking can and often results in CPU
time being spent in places - such as interrupt contexts - that do not get charged to a or the
correct process.
In fact, time spent in the processing of interrupts is a common issue for many CPU
utilization mechanisms. In particular, the “PSTAT” mechanism was eventually known to
have problems accounting for certain interrupt time prior to HP-UX 11.11 (11iv1). HP-UX
11iv2 and later are known/presumed to be good. The “KSTAT” mechanism is known to
have problems on all versions of Solaris up to and including Solaris 10. Even the microstate
accounting available via kstat in Solaris 10 has issues, though perhaps not as bad as those
of prior versions.
The /proc/stat mechanism under Linux is in what the author would consider an “un-
certain” category as it appears to be statistical, which may also have issues with time spent
processing interrupts.
In summary, be sure to “sanity-check” the CPU utilization figures with other mecha-
nisms. However, platform tools such as top, vmstat or mpstat are often based on the same
mechanisms used by netperf.