<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: sampling activity split into multiple runs but only the fir in Analyzers</title>
    <link>https://community.intel.com/t5/Analyzers/sampling-activity-split-into-multiple-runs-but-only-the-first/m-p/897710#M5166</link>
    <description>&lt;DIV style="margin:0px;"&gt;
&lt;DIV id="quote_reply" style="width: 100%; margin-top: 5px;"&gt;
&lt;DIV style="margin-left:2px;margin-right:2px;"&gt;Quoting - &lt;A href="https://community.intel.com/en-us/profile/367365"&gt;tim18&lt;/A&gt;&lt;/DIV&gt;
&lt;DIV style="background-color:#E5E5E5; padding:5px;border: 1px; border-style: inset;margin-left:2px;margin-right:2px;"&gt;&lt;EM&gt; The assumption is that the multiple runs are directly comparable, which certainly breaks down when there are competing processes running on the system. When there aren't many samples in a region of interest (most samples occurring elsewhere), there can be quite a bit of non-repeatibility entering into the comparison of the multiple runs. So, it may be helpful to set up runs to increase the time spent in a region of interest and reduce the magnitude of the problem you appear to be pointing out. You may get more insight, as you imply, by setting up individual runs which count just clock ticks and few enough other events to fit in a single run.&lt;BR /&gt;&lt;/EM&gt;&lt;/DIV&gt;
&lt;/DIV&gt;
&lt;/DIV&gt;
&lt;BR /&gt;Thanks Tim. This is along the lines of what I was thinking, but as a new user, I wanted to make sure I wasn't mis-interpreting something.&lt;BR /&gt;</description>
    <pubDate>Fri, 30 Oct 2009 01:09:55 GMT</pubDate>
    <dc:creator>sparc1998</dc:creator>
    <dc:date>2009-10-30T01:09:55Z</dc:date>
    <item>
      <title>sampling activity split into multiple runs but only the first run counts clockticks</title>
      <link>https://community.intel.com/t5/Analyzers/sampling-activity-split-into-multiple-runs-but-only-the-first/m-p/897708#M5164</link>
      <description>I have a sampling activity for which I'm trying to estimate several ratios. When I ran the activity, vtune split it into multiple runs (7 in all). It appears that CPU_CLK_UNHALTED.CORE is only sampled for the first run even though ratios computed from other runs require CPU_CLK_UNHALTED.CORE in the divsor. Does that make sense? What happens if two runs take a different number of clockticks, wouldn't that skew the ratio?&lt;BR /&gt;&lt;BR /&gt;Regards,&lt;BR /&gt;Sparc&lt;BR /&gt;</description>
      <pubDate>Thu, 29 Oct 2009 23:23:56 GMT</pubDate>
      <guid>https://community.intel.com/t5/Analyzers/sampling-activity-split-into-multiple-runs-but-only-the-first/m-p/897708#M5164</guid>
      <dc:creator>sparc1998</dc:creator>
      <dc:date>2009-10-29T23:23:56Z</dc:date>
    </item>
    <item>
      <title>Re: sampling activity split into multiple runs but only the fir</title>
      <link>https://community.intel.com/t5/Analyzers/sampling-activity-split-into-multiple-runs-but-only-the-first/m-p/897709#M5165</link>
      <description>&lt;DIV style="margin:0px;"&gt;&lt;/DIV&gt;
The assumption is that the multiple runs are directly comparable, which certainly breaks down when there are competing processes running on the system. When there aren't many samples in a region of interest (most samples occurring elsewhere), there can be quite a bit of non-repeatibility entering into the comparison of the multiple runs. So, it may be helpful to set up runs to increase the time spent in a region of interest and reduce the magnitude of the problem you appear to be pointing out. You may get more insight, as you imply, by setting up individual runs which count just clock ticks and few enough other events to fit in a single run.&lt;BR /&gt;</description>
      <pubDate>Fri, 30 Oct 2009 00:15:59 GMT</pubDate>
      <guid>https://community.intel.com/t5/Analyzers/sampling-activity-split-into-multiple-runs-but-only-the-first/m-p/897709#M5165</guid>
      <dc:creator>TimP</dc:creator>
      <dc:date>2009-10-30T00:15:59Z</dc:date>
    </item>
    <item>
      <title>Re: sampling activity split into multiple runs but only the fir</title>
      <link>https://community.intel.com/t5/Analyzers/sampling-activity-split-into-multiple-runs-but-only-the-first/m-p/897710#M5166</link>
      <description>&lt;DIV style="margin:0px;"&gt;
&lt;DIV id="quote_reply" style="width: 100%; margin-top: 5px;"&gt;
&lt;DIV style="margin-left:2px;margin-right:2px;"&gt;Quoting - &lt;A href="https://community.intel.com/en-us/profile/367365"&gt;tim18&lt;/A&gt;&lt;/DIV&gt;
&lt;DIV style="background-color:#E5E5E5; padding:5px;border: 1px; border-style: inset;margin-left:2px;margin-right:2px;"&gt;&lt;EM&gt; The assumption is that the multiple runs are directly comparable, which certainly breaks down when there are competing processes running on the system. When there aren't many samples in a region of interest (most samples occurring elsewhere), there can be quite a bit of non-repeatibility entering into the comparison of the multiple runs. So, it may be helpful to set up runs to increase the time spent in a region of interest and reduce the magnitude of the problem you appear to be pointing out. You may get more insight, as you imply, by setting up individual runs which count just clock ticks and few enough other events to fit in a single run.&lt;BR /&gt;&lt;/EM&gt;&lt;/DIV&gt;
&lt;/DIV&gt;
&lt;/DIV&gt;
&lt;BR /&gt;Thanks Tim. This is along the lines of what I was thinking, but as a new user, I wanted to make sure I wasn't mis-interpreting something.&lt;BR /&gt;</description>
      <pubDate>Fri, 30 Oct 2009 01:09:55 GMT</pubDate>
      <guid>https://community.intel.com/t5/Analyzers/sampling-activity-split-into-multiple-runs-but-only-the-first/m-p/897710#M5166</guid>
      <dc:creator>sparc1998</dc:creator>
      <dc:date>2009-10-30T01:09:55Z</dc:date>
    </item>
  </channel>
</rss>

