<html>
  <head>
    <meta content="text/html; charset=GB2312" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 15/04/2014 17:46, Yang, Guang A
      wrote:<br>
    </div>
    <blockquote
cite="mid:28F4DB836A24D74D9070047733650BEF868F24@shsmsx102.ccr.corp.intel.com"
      type="cite">
      <p class="MsoNormal"><span style="color:black" lang="EN-US">Hi
          all,<o:p></o:p></span></p>
      <p class="MsoNormal" style="text-indent:21.0pt"><span
          style="color:black" lang="EN-US">I have discussed with Daniel
          about the running time for each cases before and we set the
          standard as 10M, if one can¡¯t finish after running 10M we will
          see it as Timeout and report bug on FDO(such as :  <a
            moz-do-not-send="true"
            href="https://bugs.freedesktop.org/show_bug.cgi?id=77474"><span
              style="color:black;text-decoration:none">Bug 77474</span></a> - [PNV/IVB/HSW]igt/gem_tiled_swapping
          is slow and
          <a moz-do-not-send="true"
            href="https://bugs.freedesktop.org/show_bug.cgi?id=77475"><span
              style="color:black;text-decoration:none">Bug 77475</span></a> - [PNV/IVB/HSW]igt//kms_pipe_crc_basic/read-crc-pipe-A
          is slow)<o:p></o:p></span></p>
      <p class="MsoNormal" style="text-indent:21.0pt"><span
          style="color:black" lang="EN-US">Now the true status is that
          i-g-t have more than 650+ subcases, running a whole round of
          testing will cost such a long time on QA side(<b>beside that
            Timeout cases</b>), QA also need to spend more time to
          analysis the result changing on each platforms.<o:p></o:p></span></p>
      <p class="MsoNormal" style="text-indent:21.0pt"><span
          style="color:black" lang="EN-US">You can find an example with
          this page:</span><span lang="EN-US">
        </span><span style="color:black" lang="EN-US"><a
            moz-do-not-send="true"
            href="http://tinderbox.sh.intel.com/PRTS_UI/prtsresult.php?task_id=2778">http://tinderbox.sh.intel.com/PRTS_UI/prtsresult.php?task_id=2778</a>
          for how long one testing round cost.<o:p></o:p></span></p>
      <p class="MsoNormal" style="text-indent:21.0pt"><span
          style="color:black" lang="EN-US">With the table of
          subtask:10831 on the page which for i-g-t test cases on BDW.
          Testing start at 19:16 PM and finished at 03:25 AM the next
          day, cost about
          <b>8 hours</b> to run 638 test cases.<o:p></o:p></span></p>
      <p class="MsoNormal" style="text-indent:21.0pt"><span
          style="color:black" lang="EN-US">Each cases finished less than
          10M as we expect, but the full time it too large, especially
          the BDW is the powerful machine on our side, ILK or PNV may
          take more than
          <b>10 hours</b>. We not only run i-g-t but also need to test
          the piglit/performance/media which already need time.<o:p></o:p></span></p>
      <p class="MsoNormal" style="text-indent:21.0pt"><span
          style="color:black" lang="EN-US">Do we have any solutions to
          reduce the running time for whole i-g-t? it¡¯s a pressing
          problem for QA after seeing the i-g-t case count enhance from
          50 ->600+.</span></p>
    </blockquote>
    Ok there are a few cases where we can indeed make tests faster, but
    it will be work for us. And that won't really speed up much since
    we're adding piles more testcases at a pretty quick rate. And many
    of these new testcases are CRC based, so inheritely take some time
    to run.<br>
    <br>
    So I think longer-term we simply need to throw more machines at the
    problem and run testcases in parallel on identical machines.<br>
    <br>
    Wrt analyzing issues I think the right approach for moving forward
    is:<br>
    a) switch to piglit to run tests, not just enumerate them. This will
    allow QA and developers to share testcase analysis.<br>
    b) add automated analysis for time-consuming and error prone cases
    like dmesg warnings and backtraces. Thomas&I have just discussed
    a few ideas in this are in our 1:1 today.<br>
    <br>
    Reducing the set of igt tests we run is imo pointless: The goal of
    igt is to hit corner-cases, arbitrarily selecting which kinds of
    corner-cases we test just means that we have a nice illusion about
    our test coverage.<br>
    <br>
    Adding more people to the discussion.<br>
    <br>
    Cheers, Daniel<br>
  Intel Semiconductor AG
Registered No. 020.30.913.786-7
Registered Office: Badenerstrasse 549, 8048 Zurich, Switzerland.
</body>
</html>