Page 1 of 3 123 LastLast
Results 1 to 10 of 30

Thread: Phoronix Test Suite 1.0 Release Blockers

Hybrid View

  1. #1

    Default Phoronix Test Suite 1.0 Release Blockers

    In this thread propose features and bug fixes you would like to see addressed in Phoronix Test Suite by 1.0 "Trondheim" stage...

  2. #2
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,582

    Default

    I would consider moving the project to the opeensuse build service where it could be built for many distro's, many architectures and you would then not have to worry about bandwidth for the larger stuff.

  3. #3

    Default

    Quote Originally Posted by deanjo View Post
    I would consider moving the project to the opeensuse build service where it could be built for many distro's, many architectures and you would then not have to worry about bandwidth for the larger stuff.
    It's PHP, it's a script... Or are you referring to some other aspect of it? How would the OpenSuSE Build Service address the bandwidth needs for larger stuff?

  4. #4
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,582

    Default

    Quote Originally Posted by Michael View Post
    It's PHP, it's a script... Or are you referring to some other aspect of it? How would the OpenSuSE Build Service address the bandwidth needs for larger stuff?
    Most of the projects that you use already have repo's there compiled for various distro's and arch's. Using the build service would allow you to make installable packages for all the major distro's so all they have to do is add the repo to their favorite package manager and download.

  5. #5

    Default

    The problem with using the distro's package for the test itself is that there is no control over any compile-time optimizations or any other changes made by that package maintainer that could skew the results compared to other distro packages or the vanilla source. However, if you look at the latest development work for trondheim-pts you'll see the "External Dependencies" feature, where the distribution's packaging system is now being used in some cases for obtaining GLUT for instance as well as some other dependencies for the benchmark but not the benchmark itself.

  6. #6
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,582

    Default

    Quote Originally Posted by Michael View Post
    The problem with using the distro's package for the test itself is that there is no control over any compile-time optimizations or any other changes made by that package maintainer that could skew the results compared to other distro packages or the vanilla source. However, if you look at the latest development work for trondheim-pts you'll see the "External Dependencies" feature, where the distribution's packaging system is now being used in some cases for obtaining GLUT for instance as well as some other dependencies for the benchmark but not the benchmark itself.

    There is nothing stopping you from popping the source from your favorite project and setting up the optimization flags you want on the build service. You can set up a complete repo of all the packages you use just for use with the test suite. You do not have to depend on other people's tweaks and mods at all. Making a live distro is a snap as well if you want with kiwi. I would really recommend you look into the power of the service that they are offering.

  7. #7

    Default

    Quote Originally Posted by deanjo View Post
    There is nothing stopping you from popping the source from your favorite project and setting up the optimization flags you want on the build service. You can set up a complete repo of all the packages you use just for use with the test suite. You do not have to depend on other people's tweaks and mods at all. Making a live distro is a snap as well if you want with kiwi. I would really recommend you look into the power of the service that they are offering.
    It does sound more advanced than I had thought it was... I'll look into it.

  8. #8
    Join Date
    Apr 2008
    Posts
    34

    Default

    Quote Originally Posted by Michael View Post
    In this thread propose features and bug fixes you would like to see addressed in Phoronix Test Suite by 1.0 "Trondheim" stage...
    I'd put a note about NUM_CPU_JOBS in the README, or rig something up to set it from /proc/cpuinfo or the like. Per this thread on mplayer compilation test crashing the default NUM_CPU_JOBS of just plain leaving it blank uses too much RAM for some systems. If the test is meant to simulate juggling around dozens of active processes, this would change the test too much though.

  9. #9

    Default

    Quote Originally Posted by hwertz View Post
    I'd put a note about NUM_CPU_JOBS in the README, or rig something up to set it from /proc/cpuinfo or the like. Per this thread on mplayer compilation test crashing the default NUM_CPU_JOBS of just plain leaving it blank uses too much RAM for some systems. If the test is meant to simulate juggling around dozens of active processes, this would change the test too much though.
    This is fixed in git. It was just a simple regression when I accidentally renamed the NUM_CPU_JOBS to SYS_CPU_JOBS but didn't think about the profiles NUM_CPU_JOBS contains the number of cores (as parsed by /proc/cpuinfo) plus one. I'll likely push out PTS 0.3.1 today due to this crashing bug.

  10. #10

    Default

    Bump for 1.0 feature requests / blocker bugs.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •