[ltt-dev] Babeltrace timestamp problem
Simon Marchi
simon.marchi at polymtl.ca
Thu Aug 11 09:08:38 EDT 2011
Hello,
I think there may be a little problem with the accuracy of the
timestamps read by babeltrace.
Here is what I did:
(code available here, if you want it
http://git.dorsal.polymtl.ca/~smarchi?p=babeltrace.git;a=shortlog;h=refs/heads/timestampdebug)
1- Hijack the ctf_update_timestamp function in ctf.c so that we log in
a file all the timestamp that are read from the CTF format.
2- Have the dummy output format output log the timestamp of all
"written" events in an other file.
3- Sort the output of #1 (with coreutils sort), because at this point
they do not come out sorted.
4- Compare both. They should be identical, but they are not.
I compared a similarly formatted output of the Java parser, and it is
identical to the file of #1.
I noticed that the differences often look like this:
@@ -368,10 +368,10 @@
248813704165405
248813704165482
248813704166130
-248813704166315
248813704169065
248813704169935
248813704170150
+248813704170150
248813704171110
248813704171937
248813704176084
@@ -400,7 +400,7 @@
248813704252089
248813704252267
248813704253474
-248813704254629
+248813704255344
248813704255344
248813704255859
248813704256404
where a good timestamp (the minus in the diff) is overwritten by a
later timestamp (the plus in the diff). Sometimes, like in the first
example, they (the timestamp that gets overwritten and the timestamp
that overwrites) are not contiguous at the trace level, but every time
I checked, they were next to each other at the stream (file) level. So
that means the problem is probably somewhere in the handling of
ctf_stream.timestamp.
Simon
More information about the lttng-dev
mailing list