<div dir="ltr"><div>Scott,<br><br>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.<br>

<br>
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.<br><br>Katerina<br><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 24 September 2013 09:47, Scott Lystig Fritchie <span dir="ltr"><<a href="mailto:fritchie@snookles.com" target="_blank">fritchie@snookles.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Howdy.  I was reading this status report from the RELEASE project from<br>
earlier this year:<br>
<br>
    <a href="http://release-project.softlab.ntua.gr/documents/D2.2.pdf" target="_blank">http://release-project.softlab.ntua.gr/documents/D2.2.pdf</a><br>
<br>
I see this on page 16:<br>
<br>
    "we added timestamps to all new and existing DTrace probes that we<br>
    wanted to associate with some trace (or proling) message."<br>
<br>
As an example, on page 17:<br>
<br>
    probe message__queued(char *receiver, uint32_t size, uint32_t queue_len,<br>
        int token_label, int token_previous, int token_current,<br>
        uint64_t ts)<br>
<br>
    Parameters:<br>
    [...]<br>
    * ts: the timestamp (in microseconds)<br>
<br>
I'm a bit curious about the addition of these timestamp items to various<br>
probes.  The D2.2.pdf paper doesn't say what the timestamps are, e.g.,<br>
wallclock time-of-day (UNIX time_t/epoch-style, perhaps, but with<br>
microsecond resolution?) or relative to the start of the virtual<br>
machine, or some other basis.<br>
<br>
DTrace provides a reliable, strictly increasing timestamp value, whose D<br>
script variable name is "timestamp", which has nanosecond resolution.  A<br>
related variable, "vtimestamp", provides the time (also in nanoseconds)<br>
that the thread has been on-CPU.<br>
<br>
The SystemTap framework also supplies a similar built-in functions,<br>
e.g., gettimeofday_ns() and gettimeofday_us().<br>
<br>
It seems to me that adding the "ts" argument to the message-queued probe<br>
and others isn't Strictly Necessary(tm) for DTrace or SystemTap.  I<br>
don't know enough about LTT:NG to know if they were added to make life<br>
with LTT easier?  Thoughts?<br>
<br>
-Scott<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br></div>