test/interbench/readme

   1         Interbench - The Linux Interactivity Benchmark
   2
   3
   4         Introduction
   5
   6 This benchmark application is designed to benchmark interactivity in Linux. See
   7 the file readme.interactivity for a brief definition.
   8
   9 It is designed to measure the effect of changes in Linux kernel design or system
  10 configuration changes such as cpu, I/O scheduler and filesystem changes and
  11 options. With careful benchmarking, different hardware can be compared.
  12
  13
  14         What does it do?
  15
  16 It is designed to emulate the cpu scheduling behaviour of interactive tasks and
  17 measure their scheduling latency and jitter. It does this with the tasks on
  18 their own and then in the presence of various background loads, both with
  19 configurable nice levels and the benchmarked tasks can be real time.
  20
  21
  22         How does it work?
  23
  24 First it benchmarks how best to reproduce a fixed percentage of cpu usage on the
  25 machine currently being used for the benchmark. It saves this to a file and then
  26 uses this for all subsequent runs to keep the emulation of cpu usage constant.
  27
  28 It runs a real time high priority timing thread that wakes up the thread or
  29 threads of the simulated interactive tasks and then measures the latency in the
  30 time taken to schedule. As there is no accurate timer driven scheduling in linux
  31 the timing thread sleeps as accurately as linux kernel supports, and latency is
  32 considered as the time from this sleep till the simulated task gets scheduled.
  33
  34 Each benchmarked simulation runs as a separate process with its own threads,
  35 and the background load (if any) also runs as a separate process.
  36
  37
  38         What interactive tasks are simulated and how?
  39
  40 X:
  41 X is simulated as a thread that uses a variable amount of cpu ranging from 0 to
  42 100%. This simulates an idle gui where a window is grabbed and then dragged
  43 across the screen.
  44
  45 Audio:
  46 Audio is simulated as a thread that tries to run at 50ms intervals that then
  47 requires 5% cpu. This behaviour ignores any caching that would normally be done
  48 by well designed audio applications, but has been seen as the interval used to
  49 write to audio cards by a popular linux audio player. It also ignores any of the
  50 effects of different audio drivers and audio cards. Audio is also benchmarked
  51 running SCHED_FIFO if the real time benchmarking option is used.
  52
  53 Video:
  54 Video is simulated as a thread that tries to receive cpu 60 times per second
  55 and uses 40% cpu. This would be quite a demanding video playback at 60fps. Like
  56 the audio simulator it ignores caching, drivers and video cards. As per audio,
  57 video is benchmarked with the real time option.
  58
  59 Gaming:
  60 The cpu usage behind gaming is not at all interactive, yet games clearly are
  61 intended for interactive usage. This load simply uses as much cpu as it can
  62 get. It does not return deadlines met as there are no deadlines with an
  63 unlocked frame rate in a game. This does not accurately emulate a 3d game
  64 which is gpu bound (limited purely by the graphics card), only a cpu bound
  65 one.
  66
  67 Custom:
  68 This load will allow you to specify your own combination of cpu percentage and
  69 intervals if you have a specific workload you are interested in and know the
  70 cpu usage and frame rate of it on the hardware you are testing.
  71
  72
  73         What loads are simulated?
  74
  75 None:
  76 Otherwise idle system.
  77
  78 Video:
  79 The video simulation thread is also used as a background load.
  80
  81 X:
  82 The X simulation thread is used as a load.
  83
  84 Burn:
  85 A configurable number of threads fully cpu bound (4 by default).
  86
  87 Write:
  88 A streaming write to disk repeatedly of a file the size of physical ram.
  89
  90 Read:
  91 Repeatedly reading a file from disk the size of physical ram (to avoid any
  92 caching effects).
  93
  94 Compile:
  95 Simulating a heavy 'make -j4' compilation by running Burn, Write and Read
  96 concurrently.
  97
  98 Memload:
  99 Simulating heavy memory and swap pressure by repeatedly accessing 110% of
 100 available ram and moving it around and freeing it. You need to have some
 101 swap enabled due to the nature of this load, and if it detects no swap this
 102 load is disabled.
 103
 104 Hack:
 105 This repeatedly runs the benchmarking program "hackbench" as 'hackbench 50'.
 106 This is suggested as a real time load only but because of how extreme this
 107 load is it is not unusual for an out-of-memory kill to occur which will
 108 invalidate any data you get. For this reason it is disabled by default.
 109
 110 Custom:
 111 The custom simulation is used as a load.
 112
 113
 114         What is measured and what does it mean?
 115
 116 1. The average scheduling latency (time to requesting cpu till actually getting
 117 it) of deadlines met during the test period.
 118 2. The scheduling jitter is represented by calculating the standard deviation
 119 of the latency
 120 3. The maximum latency seen during the test period
 121 4. Percentage of desired cpu
 122 5. Percentage of deadlines met.
 123
 124 This data is output to console and saved to a file which is stamped with the
 125 kernel name and date. See sample.log.
 126
 127         Sample:
 128 --- Benchmarking simulated cpu of X in the presence of simulated ---
 129 Load    Latency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met
 130 None      0.495 +/- 0.495         45             100             96
 131 Video      11.7 +/- 11.7        1815            89.6           62.7
 132 Burn       27.9 +/- 28.1        3335            78.5             44
 133 Write      4.02 +/- 4.03         372              97           78.7
 134 Read       1.09 +/- 1.09         158            99.7             88
 135 Compile    28.8 +/- 28.8        3351            78.2           43.7
 136 Memload    2.81 +/- 2.81         187            98.7             85
 137
 138 What can be seen here is that never during this test run were all the so called
 139 deadlines met by the X simulator, although all the desired cpu was achieved
 140 under no load. In X terms this means that every bit of window movement was
 141 drawn while moving the window, but some were delayed and there was enough time
 142 to catch up before the next deadline. In the 'Burn' column we can see that only
 143 44% of the deadlines were met, and only 78.5% of the desired cpu was achieved.
 144 This means that some deadlines were so late (%deadlines met was low) that some
 145 redraws were dropped entirely to catch up. In X terms this would translate into
 146 jerky movement, in audio it would be a skip, and in video it would be a dropped
 147 frame. Note that despite the massive maximum latency of >3seconds, the average
 148 latency is still less than 30ms. This is because redraws are dropped in order
 149 to catch up usually by these sorts of applications.
 150
 151
 152         What is relevant in the data?
 153
 154 The results pessimise quite a lot what happens in real world terms because they
 155 ignore the reality of buffering, but this allows us to pick up subtle
 156 differences more readily. In terms of what would be noticed by the end user,
 157 dropping deadlines would make noticable clicks in audio, subtle visible frame
 158 time delays in video, and loss of "smooth" movement in X. Dropping desired cpu
 159 would be much more noticeable with audio skips, missed video frames or jerks
 160 in window movement under X. The magnitude of these would be best represented by
 161 the maximum latency. When the deadlines are actually met, the average latency
 162 represents how "smooth" it would look. Average humans' limit of perception for
 163 jitter is in the order of 7ms. Trained audio observers might notice much less.
 164
 165
 166         How to use it?
 167
 168 In response to critisicm of difficulty in setting up my previous benchmark,
 169 contest, I've made this as simple as possible.
 170
 171         Short version:
 172 make
 173 ./interbench
 174
 175 Please read the long version before submitting results!
 176
 177         Longer version:
 178 Build with 'make'. It is a single executable once built so if you desire to
 179 install it simply copy the interbench binary wherever you like.
 180
 181 To get good reproducible data from it you should boot into runlevel one so
 182 that nothing else is running on the machine. All power saving (cpu throttling,
 183 cpu frequency modifications) must be disabled on the first run to get an
 184 accurate measurement for cpu usage. You may enable them later if you are
 185 benchmarking their effect on interactivity on that machine. Root is almost
 186 mandatory for this benchmark, or real time privileges at the very least. You
 187 need free disk space in the directory it is being run in the order of 2* your
 188 physical ram for the disk loads. A default run in v0.21 takes about 15
 189 minutes to complete, longer if your disk is slow.
 190
 191 As the benchmark bases the work it does on the speed of the hardware the
 192 results from different hardware can not be directly compared. However changes
 193 of kernels, filesystem and options can be compared. To do a comparison of
 194 different cpus and keep the workload constant, using the -l option and
 195 passing the value of "loops_per_ms" from the first hardware tested will keep
 196 the number of cpu cycles fairly constant allowing some comparison. Future
 197 versions may add the option of setting the amount of disk throughput etc.
 198
 199
 200 Command line options supported:
 201 interbench [-l <int>] [-L <int>] [-t <int] [-B <int>] [-N <int>]
 202         [-b] [-c] [-r] [-C <int> -I <int>] [-m <comment>]
 203         [-w <load type>] [-x <load type>] [-W <bench>] [-X <bench>]
 204         [-h]
 205
 206  -l     Use <int> loops per sec (default: use saved benchmark)
 207  -L     Use cpu load of <int> with burn load (default: 4)
 208  -t     Seconds to run each benchmark (default: 30)
 209  -B     Nice the benchmarked thread to <int> (default: 0)
 210  -N     Nice the load thread to <int> (default: 0)
 211  -b     Benchmark loops_per_ms even if it is already known
 212  -c     Output to console only (default: use console and logfile)
 213  -r     Perform real time scheduling benchmarks (default: non-rt)
 214  -C     Use <int> percentage cpu as a custom load (default: no custom load)
 215  -I     Use <int> microsecond intervals for custom load (needs -C as well)
 216  -m     Add <comment> to the log file as a separate line
 217  -w     Add <load type> to the list of loads to be tested against
 218  -x     Exclude <load type> from the list of loads to be tested against
 219  -W     Add <bench> to the list of benchmarks to be tested
 220  -X     Exclude <bench> from the list of benchmarks to be tested
 221  -h     Show help
 222
 223 There is one hidden option which is not supported by default, -u
 224 which emulates a uniprocessor when run on an smp machine. The support for cpu
 225 affinity is not built in by default because there are multiple versions of
 226 the sched_setaffinity call in glibc that not only accept different variable
 227 types but across architectures take different numbers of arguments. For x86
 228 support you can change the '#if 0' in interbench.c to '#if 1' to enable the
 229 affinity support to be built in. The function on x86_64 for those very keen
 230 does not have the sizeof argument.
 231
 232
 233 Thanks:
 234 For help from Zwane Mwaikambo, Bert Hubert, Seth Arnold, Rik Van Riel,
 235 Nicholas Miell, John Levon, Miguel Freitas and Peter Williams.
 236 Aggelos Economopoulos for contest code, Bob Matthews for irman (mem_load)
 237 code, Rusty Russell for hackbench code and Julien Valroff for manpage.
 238
 239 Sat Mar 4 12:11:34 2006
 240 Con Kolivas < kernel at kolivas dot org >