There's an ever growing number of tracing use cases where we need to sync Chrome traces with other types of traces. A few such types of traces are ETW traces (for low-level Windows information), BattOr traces (which provide device power consumption data), and ftrace traces. We're building out a clock sync architecture that will allow consumers of traces - primarily trace viewer, at this point - to consume these traces and align them based on what clock they're using.

One problem that we've run into is that Chrome has somewhat complex logic around which clock it uses, and it'd be nice for the trace consumer to know what clock was being used for a given trace without having to guess. That would allow it to safely make assumptions like "Well both ETW and Chrome were using the QueryPerformanceCounter for timestamps - it's safe to assume that we can just overlay those traces without shifting timestamps."

In order to do this, we have to do two things:

1) Add a means of retrieving some sort of "Clock ID" from TimeTicks that will return the current clock (e.g. "LINUX_CLOCK_MONOTONIC_MICROS", "WIN_QPC")
2) Add the output of this TimeTicks::ClockId() to the Chrome trace metadata section (this doc - http://bit.ly/1MCMqsv - contains all discussion re: where to include that metadata)