Question

有人可以在内核日志中解释一下这个时间戳差异吗？

我们编写了一个应用程序，用于在指定时间唤醒Android，该应用程序利用AlarmManager API并设置：

AlarmManager.ELAPSED_REALTIME_WAKEUP

该应用按预期工作，并在用户指定的时间正确唤醒。但是内核时间戳存在差异。我将源代码从AlarmManagerService.java跟踪到alarm-dev.c并确认Android正确设置警报唤醒时间并将其发送到内核（例如，来自Java层Android使用SystemClock.elapsedRealtime()来过去时间并增加100秒并将值转换为秒和纳秒，最后通过JNI将其发送到内核层。

但是，在阅读dmesg日志时，似乎内核时间戳存在差异。在调用状态alarm_ioctl的{{1}}函数ANDROID_ALARM_SET(0):时，会打印以下消息：

dmesg

这意味着[20450.036529] alarm 2 set 20544.720000000是当前时间，[20450.036529]是20544.720000000唤醒Android的时间。值AlarmManager是从Android层和logcat的时间戳（例如20544.720000000）设置的，这个值是Android应该唤醒的时候。

从Android层到内核层，它需要的时间不到十分之一秒，但为什么delta为logcat -v time，比它应该小94.683471？或者经过的时间与5.316529打印的内核时间不同？

另一个有趣的观察是，如上所述，应用程序确实在用户指定的时间唤醒。因此，在这种情况下，用户调用应用程序dmesg会在100秒内唤醒平板电脑。

谢谢，

参考文献：

Answer 1

选项1

您可能希望在邮件中嵌入时间戳，而不是依赖于printk（）生成的时间戳。这种方法至少应该给你一个真正的时间测量。

选项2

您可以调查 kernel / printk.c 使用的API来获取时间戳。

如果 printk 正在使用cpu_clock（）您可能需要考虑以下事项：

CPU Clock

 14  * What:
 15  *
 16  * cpu_clock(i) provides a fast (execution time) high resolution
 17  * clock with bounded drift between CPUs. The value of cpu_clock(i)
 18  * is monotonic for constant i. The timestamp returned is in nanoseconds

使用已用时间类型设置警报会从内核中的dmesg打印不准确的延迟

1 个答案: