From: fwefew 4t4tg <7532yahoo@gmail.com>
To: users@dpdk.org
Subject: Using rdtsc to timestamp RTT of packets
Date: Sun, 5 Mar 2023 20:01:15 -0500 [thread overview]
Message-ID: <CA+Tq66WpxB7u-JxCkh7bG1Hq9+wra87QZFZXMJEA-E4FCcSLzg@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1657 bytes --]
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
The restrictions to valid use include:
- RTT (time difference) must be calculated on the same CORE
- fencing instructions (lfence) could be required
The time difference is OK provided,
- it delivers at least microsecond resolution (rdtsc does)
- the difference is always positive (end-start) or zero
- 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
- DPDK gives me the frequency rte_rdtsc_cycles(); this way I can convert
from a rdtsc difference to elapsed time
- The OS doesn't reset the counter or pause it for interrupts or on halts
I think rdtsc does all this. But then I read [1]:
- The TSC is not always invariant
- And of course context switches (if a thread is not pinned to a core)
will invalidate any time difference
- 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
So I am not so sure.
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.
What is praxis in DPDK programming when one needs RTTs?
[1]
https://stackoverflow.com/questions/42189976/calculate-system-time-using-rdtsc
[-- Attachment #2: Type: text/html, Size: 1926 bytes --]
next reply other threads:[~2023-03-06 1:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-06 1:01 fwefew 4t4tg [this message]
2023-03-06 7:56 ` Gabor LENCSE
2023-03-06 9:46 ` Van Haaren, Harry
2023-03-06 16:56 ` Stephen Hemminger
2023-03-06 17:33 ` fwefew 4t4tg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CA+Tq66WpxB7u-JxCkh7bG1Hq9+wra87QZFZXMJEA-E4FCcSLzg@mail.gmail.com \
--to=7532yahoo@gmail.com \
--cc=users@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).