Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • C codes
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 38
    • Issues 38
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 8
    • Merge requests 8
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • codes
  • codes
  • Issues
  • #146
Closed
Open
Issue created Jun 14, 2016 by Jonathan Jenkins@jenkinsContributor

better document LSM parameterization

We say to use fio, but don't have more specifics than that.

Some notes from Kevin:

“We measured I/O performance for 60 seconds at each access size as the access size was varied from 4 KiB to 8 MiB for each of sequential read, sequen- tial write, random read, and random write access patterns. The libaio engine was used in all cases with an iodepth of 4 and direct I/O. We set the model’s rate parameter to the maximum rate achieved by the sequential read and sequential write measurements. The overhead parameter was set to the median completion latency minus the transfer rate for the 4K request size. The seek parameters were set to the difference between the sequential and random latency values divided by the iodepth (4) at each request size.”

In fio, one of the output timings is “clat” or completion latency. So you take the optimal read or write transfer rate and compute a time to transfer 4K based on that, then subtract it from the clat value. That became our overhead parameter.

Overhead = clat - (4K/best_transfer_rate)

Assignee
Assign to
Time tracking