----- On Apr 27, 2017, at 8:00 AM, Frantisek Rysanek Frantisek.Rysanek@xxxxxxx wrote: > Dear gentlemen, > > thanks for your immediate and informed answers :-) > This is awesome. > > So far so good, I'm now able to trace either functions or events or > both (tested). I have yet to take a look at systemtap > (working on several fronts). When I'm done playing with this, > I intend to write a short summary (for noobs to come after me). > > For the problem that I'm trying to debug (possibly some user space > app tweaking the system timebase, need to find out the culprit) > it would be useful to reference the trace timestamps to wall time > (UTC) for a later analysis. > > I've read about /sys/kernel/debug/tracing/trace_clock and fiddled > with it, I understand that this is all I have. No problem with that, > I can calculate the wall time from the time stamps e.g. using a Perl > script - the condition being that I can get the current value of that > timer, at the time of running the Perl script. > I need to take that reference once on script startup, together with > "time" = epoch value in seconds, and a couple milliseconds of > systematic error don't matter. > > I understand that the trace timestamps are taken from some internal > counter, vaguely similar to `cat /proc/timer_list | grep "now at"` > but not quite the same, in my case there's a difference of about > 30k seconds (8.3 hours) after 177 days of system uptime. > I've tried passing other options to "trace_clock", only to find out > that the default "local" clock probably makes the best sense :-) > I'd love to get those trace timestamps referenced to UTC with > a subsecond precision. > And I don't want to reboot just to reset the counters. > = is there any item under /proc or /sys that would tell me the > current value of the "trace clock" ? > > Come to think of that, I could also pipe the "trace_pipe" > straight into a Perl script that would insert UTC timestamps on its > own, line after line, upon data arrival at (<>) - but the original > "trace clock" time stamps are more precise, and also likely free of > "system timebase frequency adjustments", which is a time domain where > I'm trying to debug a problem :-) > > As usual, any further hints would be welcome... FYI, there is another alternative: LTTng can trace specific system calls too, and offsets the monotonic time using the realtime offset, which gives you trace timestamps in GMT or localtime of the trace viewer (can be selected with a parameter passed to babeltrace). It also gathers more detailed content of many system calls, similarly to strace, but with a smaller overhead. It seems to be a good fit for the use-case you describe. For more info on basic use: http://lttng.org/docs/v2.9/#doc-getting-started Best regards, Mathieu > > Frank Rysanek > > -- > To unsubscribe from this list: send the line "unsubscribe linux-trace-users" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-trace-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|