[erlang-questions] RELEASE project D2.2 (WP2), DTrace, and timestamps

Katerina Roukounaki k4t3r1n4@REDACTED
Tue Sep 24 16:14:00 CEST 2013


Scott,

The main purpose of the work, that the report you read refers to, was to
enhance / modify the initial set of probes you had provided, so that
someone (in our case that someone was Percept) that is currently using
Erlang built-in mechanism, in order to profile an application, can use
DTrace / SystemTap to collect the same information. That work had nothing
to do with LTTng.

Having that in mind, the reason we decided to add our own time-stamps to
DTrace probes was because what we want to know is "when the event
happened", rather than "when the probe was fired" (trace messages carry
time-stamps that hold the same piece of information). The time-stamps are
generated in a way similar to that, in which the values for the ts field of
the normal trace messages are generated.

Katerina



On 24 September 2013 09:47, Scott Lystig Fritchie <fritchie@REDACTED>wrote:

> Howdy.  I was reading this status report from the RELEASE project from
> earlier this year:
>
>     http://release-project.softlab.ntua.gr/documents/D2.2.pdf
>
> I see this on page 16:
>
>     "we added timestamps to all new and existing DTrace probes that we
>     wanted to associate with some trace (or proling) message."
>
> As an example, on page 17:
>
>     probe message__queued(char *receiver, uint32_t size, uint32_t
> queue_len,
>         int token_label, int token_previous, int token_current,
>         uint64_t ts)
>
>     Parameters:
>     [...]
>     * ts: the timestamp (in microseconds)
>
> I'm a bit curious about the addition of these timestamp items to various
> probes.  The D2.2.pdf paper doesn't say what the timestamps are, e.g.,
> wallclock time-of-day (UNIX time_t/epoch-style, perhaps, but with
> microsecond resolution?) or relative to the start of the virtual
> machine, or some other basis.
>
> DTrace provides a reliable, strictly increasing timestamp value, whose D
> script variable name is "timestamp", which has nanosecond resolution.  A
> related variable, "vtimestamp", provides the time (also in nanoseconds)
> that the thread has been on-CPU.
>
> The SystemTap framework also supplies a similar built-in functions,
> e.g., gettimeofday_ns() and gettimeofday_us().
>
> It seems to me that adding the "ts" argument to the message-queued probe
> and others isn't Strictly Necessary(tm) for DTrace or SystemTap.  I
> don't know enough about LTT:NG to know if they were added to make life
> with LTT easier?  Thoughts?
>
> -Scott
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130924/d158f25a/attachment.htm>


More information about the erlang-questions mailing list