All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Maciej Żenczykowski" <maze@google.com>
To: Daniel Xu <dxu@dxuuu.xyz>
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
	bimmy.pujari@intel.com, bpf <bpf@vger.kernel.org>,
	Networking <netdev@vger.kernel.org>,
	mchehab@kernel.org, Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>, Martin Lau <kafai@fb.com>,
	ashkan.nikravesh@intel.com
Subject: Re: [PATCH] bpf: Add bpf_ktime_get_real_ns
Date: Tue, 18 Aug 2020 14:19:24 -0700	[thread overview]
Message-ID: <CANP3RGcVidrH6Hbne-MZ4YPwSbtF9PcWbBY0BWnTQC7uTNjNbw@mail.gmail.com> (raw)
In-Reply-To: <C50F3QS9W4JM.1OIVL1ZHWEIWI@maharaja>

On Tue, Aug 18, 2020 at 2:11 PM Daniel Xu <dxu@dxuuu.xyz> wrote:
>
> On Mon Jul 27, 2020 at 10:01 PM PDT, Andrii Nakryiko wrote:
> > On Mon, Jul 27, 2020 at 4:35 PM <bimmy.pujari@intel.com> wrote:
> > >
> > > From: Ashkan Nikravesh <ashkan.nikravesh@intel.com>
> > >
> > > The existing bpf helper functions to get timestamp return the time
> > > elapsed since system boot. This timestamp is not particularly useful
> > > where epoch timestamp is required or more than one server is involved
> > > and time sync is required. Instead, you want to use CLOCK_REALTIME,
> > > which provides epoch timestamp.
> > > Hence add bfp_ktime_get_real_ns() based around CLOCK_REALTIME.
> > >
> >
> > This doesn't seem like a good idea. With time-since-boot it's very
> > easy to translate timestamp into a real time on the host.
>
> For bpftrace, we have a need to get millisecond-level precision on
> timestamps. bpf has nanosecond level precision via
> bpf_ktime_get[_boot]_ns(), but to the best of my knowledge userspace
> doesn't have a high precision boot timestamp.
>
> There's /proc/stat's btime, but that's second-level precision. There's
> also /proc/uptime which has millisecond-level precision but you need to
> make a second call to get current time. Between those two calls there
> could be some unknown delta. For millisecond we could probably get away
> with calculating a delta and warning on large delta but maybe one day
> we'll want microsecond-level precision.
>
> I'll probably put up a patch to add nanoseconds to btime (new field in
> /proc/stat) to see how it's received. But either this patch or my patch
> would work for bpftrace.
>
> [...]
>
> Thanks,
> Daniel

Not sure what problem you're trying to solve and thus what exactly you
need... but you can probably get something very very close with 1 or 2
of clock_gettime(CLOCK_{BOOTTIME,MONOTONIC,REALTIME}) possibly in a
triple vdso call sandwich and iterated a few times and picking the one
with smallest delta between 1st and 3rd calls.  And then assuming the
avg of 1st and 3rd matches the 2nd.
ie.

5 times do:
t1[i] = clock_gettime(REALTIME)
t2[i] = clock_gettime(BOOTTIME)
t3[i] = clock_gettime(REALTIME)

pick i so t3[i] - t1[i] is smallest

t2[i] is near equivalent to (t1[i] + t3[i]) / 2

which basically gives you a REAL to BOOT offset.

  reply	other threads:[~2020-08-18 21:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-27 23:34 [PATCH] bpf: Add bpf_ktime_get_real_ns bimmy.pujari
2020-07-27 23:52 ` Song Liu
2020-07-28  5:01 ` Andrii Nakryiko
     [not found]   ` <CANP3RGd2fKh7qXyWVeqPM8nVKZRtJrJ65apmGF=w9cwXy6TReQ@mail.gmail.com>
2020-07-28 18:28     ` Andrii Nakryiko
2020-07-28 20:57       ` David Ahern
2020-07-29  5:15         ` Andrii Nakryiko
2020-07-29 14:08           ` David Ahern
     [not found]       ` <BYAPR11MB3752ECD1819CE1B987D0B07288730@BYAPR11MB3752.namprd11.prod.outlook.com>
2020-07-29  5:09         ` Andrii Nakryiko
2020-08-18 20:50   ` Daniel Xu
2020-08-18 21:19     ` Maciej Żenczykowski [this message]
2020-08-18 23:03       ` Daniel Xu

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=CANP3RGcVidrH6Hbne-MZ4YPwSbtF9PcWbBY0BWnTQC7uTNjNbw@mail.gmail.com \
    --to=maze@google.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=ashkan.nikravesh@intel.com \
    --cc=ast@kernel.org \
    --cc=bimmy.pujari@intel.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=dxu@dxuuu.xyz \
    --cc=kafai@fb.com \
    --cc=mchehab@kernel.org \
    --cc=netdev@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.