Timestamps can be resolved against the same CLOCK_REALTIME timestamp). In this case converting a CLOCK_BOOTTIME timestamp toĬLOCK_REALTIME is always possible without ambiguities (eventually two distinct Such a trace would contain several snapshots that break bijectivity between the Real-time clock jumps back from 3AM to 2AM. If non-monotonicity is detected at import time, the clock domain is excluded asĪ source path in the graph search and is allowed only as a target path.įor instance, imagine capturing a trace that has both CLOCK_BOOTTIMEĪnd CLOCK_REALTIME in the night when daylight saving is applied, when the The timestamp_clock_id field of TracePacket message TracePacketĬLOCK_BOOTTIME = ( 3703 - 1200) + 5200 = 7703 CaveatsĬlock resolution between two domains (A,B) is allowed only as long as all theĬlock domains in the A -> B path are monotonic (or at least look so in the
#Multiclock domain synchronization android#
On Linux/Android, Ftrace events are emitted using the CLOCK_BOOTTIME clock,īut the Android event log uses CLOCK_REALTIME. In a complex multi-producer scenario, different data source can emit events
Trace time, as long as the ClockSnapshot packets are present in To rebuild the clock graph and use that to re-synchronize events on a global On top of the default set of builtin clock domains, new clockĭomains can be dynamically created at trace-time.Ĭlock domains are allowed to drift from each other.Īt import time, Perfetto's Trace Processor is able Synchronization of multiple clock domainsĪs per 6756fb05 Perfetto handles events using differentĬlock domains.