<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 12/21/2017 6:29 PM, Lionel
      Landwerlin wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:62813062-eba1-0fa2-1959-6abf19e3dcae@intel.com">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <div class="moz-cite-prefix">Some more findings I made while
        playing with this series & GPUTop.<br>
        Turns out the 2ms drift per second is due to timecounter. Adding
        the delta this way :<br>
        <br>
        <a class="moz-txt-link-freetext"
href="https://github.com/djdeath/linux/commit/7b002cb360483e331053aec0f98433a5bd5c5c3f#diff-9b74bd0cfaa90b601d80713c7bd56be4R607"
          moz-do-not-send="true">https://github.com/djdeath/linux/commit/7b002cb360483e331053aec0f98433a5bd5c5c3f#diff-9b74bd0cfaa90b601d80713c7bd56be4R607</a><br>
        <br>
        Eliminates the drift.</div>
    </blockquote>
    I see two imp. changes 1. approximation of start time during
    init_timecounter 2. overflow handling in delta accumulation.<br>
    With these incorporated, I guess timecounter should also work in
    same fashion.<br>
    <blockquote type="cite"
      cite="mid:62813062-eba1-0fa2-1959-6abf19e3dcae@intel.com">
      <div class="moz-cite-prefix"> Timelines of perf i915 tracepoints
        & OA reports now make a lot more sense.<br>
        <br>
        There is still the issue that reading the CPU clock & the
        RCS timestamp is inherently not atomic. So there is a delta
        there.<br>
        I think we should add a new i915 perf record type to express the
        delta that we measure this way :<br>
        <br>
        <a class="moz-txt-link-freetext"
href="https://github.com/djdeath/linux/commit/7b002cb360483e331053aec0f98433a5bd5c5c3f#diff-9b74bd0cfaa90b601d80713c7bd56be4R2475"
          moz-do-not-send="true">https://github.com/djdeath/linux/commit/7b002cb360483e331053aec0f98433a5bd5c5c3f#diff-9b74bd0cfaa90b601d80713c7bd56be4R2475</a><br>
        <br>
        So that userspace knows there might be a global offset between
        the 2 times and is able to present it.<br>
      </div>
    </blockquote>
    agree on this. Delta ns1-ns0 can be interpreted as max drift.<br>
    <blockquote type="cite"
      cite="mid:62813062-eba1-0fa2-1959-6abf19e3dcae@intel.com">
      <div class="moz-cite-prefix"> Measurement on my KBL system were in
        the order of a few microseconds (~30us).<br>
        I guess we might be able to setup the correlation point better
        (masking interruption?) to reduce the delta.<br>
      </div>
    </blockquote>
    already using spin_lock. Do you mean NMI?<br>
    <blockquote type="cite"
      cite="mid:62813062-eba1-0fa2-1959-6abf19e3dcae@intel.com">
      <div class="moz-cite-prefix"> <br>
        Thanks,<br>
        <br>
        -<br>
        Lionel<br>
        <br>
        <br>
        On 07/12/17 00:57, Robert Bragg wrote:<br>
      </div>
      <blockquote type="cite"
cite="mid:CAMou1-2Z7=A_GBcD9a5AvjRGM3_bG-ezoZJnGYvXkrCqqrmT1w@mail.gmail.com">
        <div dir="ltr"><br>
          <div class="gmail_extra"><br>
            <div class="gmail_quote">On Thu, Dec 7, 2017 at 12:48 AM,
              Robert Bragg <span dir="ltr"><<a
                  href="mailto:robert@sixbynine.org" target="_blank"
                  moz-do-not-send="true">robert@sixbynine.org</a>></span>
              wrote:<br>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">
                <div dir="ltr"><br>
                </div>
              </blockquote>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">
                <div dir="ltr">
                  <div class="gmail_extra">
                    <div class="gmail_quote">
                      <div> at least from what I wrote back then it
                        looks like I was seeing a drift of a few
                        milliseconds per second on SKL. I vaguely recall
                        it being much worse given the frequency
                        constants we had for Haswell.<br>
                      </div>
                    </div>
                  </div>
                </div>
              </blockquote>
              <div><br>
              </div>
              <div>Sorry I didn't actually re-read my own message
                properly before referencing it :) Apparently the 2ms per
                second drift was for Haswell, so presumably not quite so
                bad for SKL. <br>
              </div>
              <div><br>
              </div>
              <div>- Robert<br>
              </div>
            </div>
            <br>
          </div>
        </div>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
Intel-gfx mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Intel-gfx@lists.freedesktop.org" moz-do-not-send="true">Intel-gfx@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/intel-gfx" moz-do-not-send="true">https://lists.freedesktop.org/mailman/listinfo/intel-gfx</a>
</pre>
      </blockquote>
      <p><br>
      </p>
    </blockquote>
    <br>
  </body>
</html>