On Thu 2020-09-24 10:07:57, Mark Salyzyn wrote: > I would hope for monotonic_raw, boottime and realtime as being the most > useful for most situations. > > [TL;DR] > > Currently kernel logs actually uses monotonic_raw (no timing clock > correction), not monotonic (timing correction). > > Whereas boot (timing clock adjusted, still monotonic) and realtime (timing > clock _and_ time adjusted, non monotonic), when we try to correlate to user > space is workable, but we will have troubles correlating monotonic (w.r.t. > monotonic_raw) clocks if used in user space. > > In Android we have the option of monotonic and realtime only right now for > the user space logger (which integrates logd, klogd and auditd, the later > two come from the kernel). I have bugs open to consider boottime, but it is > blocked on boottime availability from kernel space logging (this change). I > have another bug to consider switching the logger to monotonic_raw instead > of monotonic, to make it correlate better with existing kernel logs. But > alas a lot of resistance for phones switching to monotonic(_raw), the only > devices that chose monotonic(_raw) is everything else (google glass, > watches, ...). As such, phones, and the associated developers, will > continue to want realtime correlated in the kernel logs (yes, this change > too). > > realtime sucks for the first 10 seconds on Android, since phones generally > do not get their time correction until then from network resources, and > many of their rtc clocks are not adjustable, they store a correction factor > that does not get picked up from user space until userdata is mounted > (about 20 seconds in). But only kernel developers care about this first > part of boot, everything after that (and associated correlated kernel > interactions) are for user space folks.
Thanks a lot for this detailed feedback. Just to be sure that I understand it correctly. You suggest to store three timestamps: local_clock(), boot and real clock. It makes sense to me. I just wonder if there might be any use case when the adjusted mono clock is needed or preferred over local_clock(). Best Regards, Petr
