Announcement

Collapse
No announcement yet.

Adding tests on application- and system-level latency related to I/O

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Adding tests on application- and system-level latency related to I/O

    Hi,
    I'm one of the authors of the BFQ I/O scheduler, and I would like to add tests (to the phoronix test suite), to measure the latencies that the user of a personal or a server experiences because of I/O.

    The first test I have in mind measures the time that it takes to start an application, with cold caches, and while some configurable I/O is in progress in the background. For example, the typical application considered for this test in my S suite is a terminal. Is adding such a test feasible? I'm thinking mainly about dependencies (the application to start, a suitable running graphic environment, ...).

    If it is feasible, would it be interesting to have such a test in the official version of the suite?

    Thanks,
    Paolo

  • #2
    Hi paolo definitely would be interested in any new tests around I/O. If you have some current test cases where they can be executed from the CLI nicely and end gracefully and output some interesting data, from there I can provide some guidance on how to write a test profile for it for PTS.
    Michael Larabel
    http://www.michaellarabel.com/

    Comment


    • #3
      Originally posted by Michael View Post
      Hi paolo definitely would be interested in any new tests around I/O. If you have some current test cases where they can be executed from the CLI nicely and end gracefully and output some interesting data, from there I can provide some guidance on how to write a test profile for it for PTS.
      I have it. Would you be available for a quick video call, so that I can show you both test, as well as any detail that you may find relevant to help? Otherwise how do you prefer me to share information?

      BTW, the S suite is here:
      https://github.com/Algodev-github/S
      and the first test I'm thinking about is named comm_startup_lat

      Comment


      • #4
        Originally posted by paolo View Post

        I have it. Would you be available for a quick video call, so that I can show you both test, as well as any detail that you may find relevant to help? Otherwise how do you prefer me to share information?

        BTW, the S suite is here:
        https://github.com/Algodev-github/S
        and the first test I'm thinking about is named comm_startup_lat
        I'll take a look at the test over the next couple days as soon as time allows and get back to you, you can always email me at michael at phoronix.com.
        Michael Larabel
        http://www.michaellarabel.com/

        Comment


        • #5
          Originally posted by paolo View Post

          I have it. Would you be available for a quick video call, so that I can show you both test, as well as any detail that you may find relevant to help? Otherwise how do you prefer me to share information?

          BTW, the S suite is here:
          https://github.com/Algodev-github/S
          and the first test I'm thinking about is named comm_startup_lat
          Hi paolo, for the comm_startup_lat.sh do you have some recommended configurations for testing? Short of exposing all the tunables/option combinations to PTS, just trying to figure out some sane options to try without overloading the user with so many options.
          Michael Larabel
          http://www.michaellarabel.com/

          Comment


          • #6
            Originally posted by Michael View Post

            Hi paolo, for the comm_startup_lat.sh do you have some recommended configurations for testing? Short of exposing all the tunables/option combinations to PTS, just trying to figure out some sane options to try without overloading the user with so many options.
            Definitely. For my batches of tests, I use the higher-level script run_main_benchmarks.sh. And that one tries with the following background workloads: ten seq readers, ten random readers, five seq readers + five seq writers, five rand readers + five rand writers. In addition, the script run_main_benchmarks.sh tries with several target apps: bash, xterm, gnome-terminal and lowriter. Anyway, there is no special motivation behind these choices: it's just an attempt to cover enough cases. I'm willing to use (only) the cases you deem more sensible for the PTS.

            BTW, today I'll see some people to hopefully start at least to familiarize with the PTS. If you agree, as a very first step, we would like to understand how to reconfigure existing PTS I/O tests so as to use BFQ the right way. I mean: as of now these tests use BFQ in its default configuration, which is aimed at a low latency for interactive and son real-time applications, even at the cost of sacrificing throughput. But then the tests measure only throughput. My idea is then to make these tests configure BFQ the right way, i.e., simply switch off the low-latency feature (through the low_latency knob) at the beginning of the test. What do you think? If this first contribution is ok for you, do you have suggestions on how to best achieve such a result?

            Comment


            • #7
              Hi Michael, did you have time to look into my reply and further questions?

              In particular, as a very first contribution, I would like to integrate current PTS I/O tests so as to properly configure BFQ, if this makes sense.

              Comment

              Working...
              X