Well, I forgot step 2.5, run babeltrace on a trace. Simon
On Thu, Aug 11, 2011 at 09:08, Simon Marchi <[email protected]> wrote: > 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 > _______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
