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
