Messages in this thread | | | Date | Thu, 11 Dec 2014 21:22:59 +0100 | From | Sebastian Andrzej Siewior <> | Subject | Re: [PATCH 4/8] perf data: Add a 'perf' prefix to the generic fields |
| |
On 12/11/2014 08:47 PM, David Ahern wrote: > On 12/11/14 11:57 AM, Sebastian Andrzej Siewior wrote: >>>> $ babeltrace ./ctf-data/ >>>> [03:19:13.962131936] (+0.000001935) cycles: { }, { perf_ip = >>>> 0xFFFFFFFF8105443A, perf_tid = 20714, perf_pid = 20714, perf_period >>>> = 8 } >>>> [03:19:13.962133732] (+0.000001796) cycles: { }, { perf_ip = >>>> 0xFFFFFFFF8105443A, perf_tid = 20714, perf_pid = 20714, perf_period = >>>> 114 } >>>> ... >>> >>> How is babeltrace showing time-of-day for perf-based data files? Is that >>> tod when the command is run? >> >> CTF needs an a base offset which we set to 0 because we don't have it. >> It then takes the NS timestamp and computes the "time". > > so the perf-clock timestamp is converted to hour-min-second-nsec. That > is even more confusing - for me at least.
This is the default view of babeltrace. You can switch it off and see the timestamp in (base + ns).
> By base offset you mean the conversion between perf-clock and realtime? yes.
> What if that information is known (e.g., my tree at > https://github.com/dsahern/linux as time-of-day support through a klm) - > what's the ctf function to set the base offset? Can it be changed as a > file is processed - e.g., tracepoints capturing ntp adjustments?
Not sure I can follow here. If I'm not mistaken, the perf-clock starts at 0 at boot time and is then incremented. If you manage to compute the offset between perf-clock "0" and current-time at-this point then you can use this as "base". That means, perf-timestamp + base is the time+date when this event was captured. This base offset isn't stored in the perf stream. If you look at ctf_writer__setup_clock() (patch #3) it sets the offset I refer to. This offset can be set only once and can't be adjusted.
> David
Sebastian
| |