Meta Configuration of home:pkirsch:Benchmark:Bonnie

Overview Repositories Monitor Requests Users Subprojects Project Config Attributes Signing Keys Meta Status Pulse

Meta Configuration of home:pkirsch:Benchmark:Bonnie

<project name="home:pkirsch:Benchmark:Bonnie">
  <title>Bonnie</title>
  <description>Bonnie is a file system Benchmark.
From the documentation (readme.html):
  • Test Details
      □ The file IO tests are:
         1. Sequential Output
             1. Per-Character. The file is written using the putc() stdio macro. The loop that does the writing should be
                small enough to fit into any reasonable I-cache. The CPU overhead here is that required to do the stdio code
                plus the OS file space allocation.
             2. Block. The file is created using write(2). The CPU overhead should be just the OS file space allocation.
             3. Rewrite. Each BUFSIZ of the file is read with read(2), dirtied, and rewritten with write(2), requiring an
                lseek(2). Since no space allocation is done, and the I/O is well-localized, this should test the effectiveness
                of the filesystem cache and the speed of data transfer.
         2. Sequential Input
             1. Per-Character. The file is read using the getc() stdio macro. Once again, the inner loop is small. This should
                exercise only stdio and sequential input.
             2. Block. The file is read using read(2). This should be a very pure test of sequential input performance.
         3. Random Seeks
            This test runs SeekProcCount processes (default 3) in parallel, doing a total of 8000 lseek()s to locations in the
            file specified by random() in bsd systems, drand48() on sysV systems. In each case, the block is read with read
            (2). In 10% of cases, it is dirtied and written back with write(2).
            The idea behind the SeekProcCount processes is to make sure there's always a seek queued up.
            AXIOM: For any unix filesystem, the effective number of lseek(2) calls per second declines asymptotically to near
            30, once the effect of caching is defeated.
</description>
  <person userid="pkirsch" role="maintainer"/>
  <build>
    <disable/>
  </build>
</project>

Places

Meta Configuration of home:pkirsch:Benchmark:Bonnie

Places