<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Please see my comments inline.<br>
    </p>
    <div class="moz-cite-prefix">On 3/6/2023 2:01 AM, fwefew 4t4tg
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CA+Tq66WpxB7u-JxCkh7bG1Hq9+wra87QZFZXMJEA-E4FCcSLzg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">I convinced myself that a viable way to measure
        timestamps between a request packet and its response packet can
        be the difference between two Intel rdtsc calls<br>
      </div>
    </blockquote>
    I think it is a good solution:  computationally inexpensive and
    accurate.<br>
    <blockquote type="cite"
cite="mid:CA+Tq66WpxB7u-JxCkh7bG1Hq9+wra87QZFZXMJEA-E4FCcSLzg@mail.gmail.com">
      <div dir="ltr"><br>
        The restrictions to valid use include:<br>
        <ul>
          <li>RTT (time difference) must be calculated on the same CORE</li>
        </ul>
      </div>
    </blockquote>
    <p>Yes, it is safe. <br>
    </p>
    <p>But I think it is also OK, if the two cores used for taking
      sending TSC and receiving TSC belong to the same physical CPU. At
      least it works me well in my measurement program called siitperf.<br>
    </p>
    <blockquote type="cite"
cite="mid:CA+Tq66WpxB7u-JxCkh7bG1Hq9+wra87QZFZXMJEA-E4FCcSLzg@mail.gmail.com">
      <div dir="ltr">
        <ul>
          <li>fencing instructions (lfence) could be required</li>
        </ul>
      </div>
    </blockquote>
    <p>But it can also decrease the performance of your program. <br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CA+Tq66WpxB7u-JxCkh7bG1Hq9+wra87QZFZXMJEA-E4FCcSLzg@mail.gmail.com">
      <div dir="ltr">
        <div>The time difference is OK provided,</div>
        <div>
          <ul>
            <li>it delivers at least microsecond resolution (rdtsc does)</li>
            <li>the difference is always positive (end-start) or zero</li>
            <li>the details of whether the clock runs or does not run at
              the processor speed is not material so long as there's
              sufficient resolution</li>
            <li>DPDK gives me the frequency rte_rdtsc_cycles(); this way
              I can convert from a rdtsc difference to elapsed time</li>
            <li>The OS doesn't reset the counter or pause it for
              interrupts or on halts<br>
            </li>
          </ul>
        </div>
        I think rdtsc does all this. But then I read [1]:<br>
        <ul>
          <li>The TSC is not always invariant</li>
          <li>And of course context switches (if a thread is not pinned
            to a core) will invalidate any time difference</li>
        </ul>
      </div>
    </blockquote>
    I start the packet sender and receiver threads by the <span
      class="pl-c1">rte_eal_remote_launch() calls on the appropriate
      cores and i</span>t works fine for me.<span class="pl-c1"></span>
    <blockquote type="cite"
cite="mid:CA+Tq66WpxB7u-JxCkh7bG1Hq9+wra87QZFZXMJEA-E4FCcSLzg@mail.gmail.com">
      <div dir="ltr">
        <ul>
          <li>The TSC is not incremented when the processor enters a
            deep sleep. I don't care about this because I'll turn off
            the power saving modes anyway</li>
        </ul>
        So I am not so sure.</div>
    </blockquote>
    I set the CPU clock frequency to a fixed value. (If I cannot do it
    from BIOS, I use the tlp Linux package.)<br>
    <blockquote type="cite"
cite="mid:CA+Tq66WpxB7u-JxCkh7bG1Hq9+wra87QZFZXMJEA-E4FCcSLzg@mail.gmail.com">
      <div dir="ltr"> 
        <div><br>
        </div>
        <div>Now, of course, Mellanox can report time stamps. Is it
          actually possible to get HW NIC timestamps reported for every
          packet sent and received without overburdening the NIC? Based
          on what I can see for my case (Connect 4 LX) resolution is
          nanoseconds. So I am tempted to not fool around with rdtsc and
          just use NIC timestamps.<br>
          <br>
          What is praxis in DPDK programming when one needs RTTs?<br>
        </div>
      </div>
    </blockquote>
    <p>I have implemented both the Latency and PDV (Packet Delay
      Variation) measurements of RFC 8219 in siitperf using RDTSC. I am
      satisfied with the result.</p>
    <p>If you are interested, you can find the source code here:
      <a class="moz-txt-link-freetext" href="https://github.com/lencsegabor/siitperf">https://github.com/lencsegabor/siitperf</a></p>
    <p>And its latest version is documented in my paper:
<a class="moz-txt-link-freetext" href="http://www.hit.bme.hu/~lencse/publications/ECC-2022-SFNATxy-Tester-published.pdf">http://www.hit.bme.hu/~lencse/publications/ECC-2022-SFNATxy-Tester-published.pdf</a></p>
    <p>Best regards,</p>
    <p>Gábor</p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CA+Tq66WpxB7u-JxCkh7bG1Hq9+wra87QZFZXMJEA-E4FCcSLzg@mail.gmail.com">
      <div dir="ltr">
        <div>
          <div><br>
          </div>
          <div>[1] <a
href="https://stackoverflow.com/questions/42189976/calculate-system-time-using-rdtsc"
              moz-do-not-send="true" class="moz-txt-link-freetext">https://stackoverflow.com/questions/42189976/calculate-system-time-using-rdtsc</a></div>
        </div>
      </div>
    </blockquote>
  </body>
</html>