Lines Matching refs:clock

1 # Synchronization of multiple clock domains
4 clock domains. On top of the default set of builtin clock domains, new clock
9 to rebuild the clock graph and use that to re-synchronize events on a global
16 using different clock domains.
20 * On Linux/Android, Ftrace events are emitted using the `CLOCK_BOOTTIME` clock,
26   hardware clock source that drifts from the system clock.
31 To solve this, we allow events to be recorded with different clock domains and
32 re-synchronize them at import time using clock snapshots.
47   // Specifies the ID of the clock used for the TracePacket |timestamp|. Can be
49   // producer-defined clock id.
55 This (optional) field determines the clock domain for the packet.
56 If omitted it refers to the default clock domain of the trace
63 * A custom sequence-scoped clock, with 64 <= ID < 128
64 * A custom globally-scoped clock, with 128 <= ID < 2**32
74 Sequence-scoped clocks are application-defined clock domains that are valid only
80 This covers the most common use case of a clock domain that is used only within
85 In order to make use of a custom sequence-scoped clock domain a data source
95 * Must be emitted before the custom clock is referred to by any `TracePacket`
97 * Must contain a snapshot of: (i) the custom clock id [64, 127] and (ii) another
98   clock domain that can be resolved, at import time, against the default trace
99   clock domain (`CLOCK_BOOTTIME`) (see the [Operation section](#operation)
103 are okay. E.g., two data sources, unaware of each other, can both use clock ID
104 64 to refer to two different clock domains.
107 Globally-scoped clock domains work similarly to sequence-scoped clock domains,
112 a `ClockSnapshot` defines a clock domain with ID >= 128, that clock domain can
115 Care must be taken to avoid collisions between global clock domains defined by
121 * Chose a fully qualified name for the clock domain
123 * Chose the clock ID as `HASH("com.example.my_subsystem") | 0x80000000`
124   where `HASH(x)` is the FNV-1a hash of the fully qualified clock domain name.
129 more clock domains. It conveys the notion *"at this point in time, the timestamp
130 of the clock domains X,Y,Z was 1000, 2000, 3000."*.
133 information to establish a mapping between these clock domain. For instance,
134 to realize that 1042 on clock domain X == 3042 on clock domain Z.
137 clock domains on a regular basis.
139 A data source should emit `ClockSnapshot` packets only when using custom clock
142 It is *not* mandatory that the `ClockSnapshot` for a custom clock domain
144 so when possible). The Trace Processor can deal with multi-path clock domain
150 TracePacket down to the trace clock domain (`CLOCK_BOOTTIME`) using the
166 `timestamp=1104` is seen, the clock sync logic will:
170 2. Compute the clock domain conversion to `CLOCK_BOOTTIME` by applying the
174 The example above is rather simple, because the source clock domain  (i.e. the
175 one specified by the `timestamp_clock_id` field) and the target clock domain
183 queried to perform clock domain conversions. All types of clock domains can be
186 In the more general case, the clock domain conversion logic operates as follows:
188 * The shortest path between the source and target clock domains is identified,
190 * For each clock domain of the path identified, the timestamp is converted using
223 clock domains in the A -> B path are monotonic (or at least look so in the
225 If non-monotonicity is detected at import time, the clock domain is excluded as
230 real-time clock jumps back from 3AM to 2AM.
233 two clock domains. In this case converting a `CLOCK_BOOTTIME` timestamp to