google / perfetto

Performance instrumentation and tracing for Android, Linux and Chrome (read-only mirror of https://android.googlesource.com/platform/external/perfetto/)

Home Page:https://www.perfetto.dev

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Does the SDK TRACE_EVENT/COUNTER_EVENT respect the primary_trace_clock?

ztlevi opened this issue · comments

Hi,

I set the primary_trace_clock like this in the config https://github.com/ztlevi/perfetto-trace-example/blob/main/data_generator_test.cc#L29-L31. But the recorded packets still use BOOT_TIME, including tracing_started/disabled packets and counter and event packets.

What's the proper of changing the primary clock?

The trace example is here https://github.com/ztlevi/perfetto-trace-example/blob/main/example.pftrace.

Thanks!

As noted in the proto (https://cs.android.com/android/platform/superproject/+/master:external/perfetto/protos/perfetto/config/trace_config.proto;l=93?q=primary_trace_clock), the purpose of PRIMARY_TRACE_CLOCK is not to change the timestamps within the trace itself but is instead a signal to trace processor to convert timestamps to the clock specified.

TrackEvent and all ftrace events will still use BOOTTIME (by default) because it's the "best" (monotonic, accounts for suspend etc.) but consumers (e.g. Chrome) may prefer different clock when performing analysis; primary_trace_clock encodes this precise functionality.

If you want to set a custom timestamp/clock domain in the trace, you need to provide the timestamp to the macro  as a typed struct and define perfetto::TraceTimestampTraits<T>::ConvertTimestampToTraceTimeNs for your type T as described at https://cs.android.com/android/platform/superproject/+/master:external/perfetto/include/perfetto/tracing/track_event.h;l=233?q=track_event%20f:perfetto%20f:.h

Thanks for the reply!

Our use case is to record traces across machines. So use REAL_TIME might be simpler for us.

I realize traces are aligned with clock snapshots. If record across machines, should we use different trusted_packet_sequence_id along with suquence_flags 2?

I'm not sure how the clock snapshots are aligned. Is the logic inside your UI codes?

Thanks!

Our use case is to record traces across machines. So use REAL_TIME might be simpler for us.

Yes REAL_TIME would probably be the correct choice in your case. Just ensure that your clocks are synced between your machines with NTP etc to minimise drift.

I realize traces are aligned with clock snapshots. If record across machines, should we use different trusted_packet_sequence_id along with suquence_flags 2?

You definitely need to use different trusted_packet_sequence_id. SEQ_NEEDS_INCREMENTAL_STATE needs to be set anywhere you use IncrementalState (i.e. interning).

I'm not sure how the clock snapshots are aligned. Is the logic inside your UI codes?

The logic lives inside trace processor (i.e. the "backend" of the UI) - specifically in the ClockTracker class. You can read about how this alignment happens in this docs page