2

This question is not related to the pause/resume issue!

For the same event 'dmesg' shows always the same time stamp, e.g.

[31765279.760248]

However when using 'dmesg -T', for the same event it shows slightly different seconds count, e.g. calling dmesg -T | grep something | tail -1 twice results in:

[Thu Jan 29 01:12:39 2015] event details...
[Thu Jan 29 01:12:38 2015] event details...

I need to compare events with history and act on new events. However this difference makes it impossible to use a simple string compare.

As a work around I clip the seconds from the strings before I compare them. I can do it in this case since the events I filter do not happen more than once in 5 minutes.

Does anyone know why this inaccuracy happens?

uname -a => Linux (hostname) 3.5.0-45-generic #68~precise1-Ubuntu SMP Wed Dec 4 16:18:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Daniel BenDavid
  • 31
  • 3
  • I have no explanation for the inconsistency you're seeing, but allow me a silly question: why don't you do the comparison on the raw-value and convert it to human readable manually later if needed? – tink Feb 01 '15 at 21:32
  • I'm lazy :) I know there are several workarounds and I'm using one, but I'm curious to know the reason. Thanks for the quick response – Daniel BenDavid Feb 01 '15 at 21:37

1 Answers1

0

Those timestamps are converted to real time by adding them to the system boot time. If the system came up at 1491516481.480856282 and you add a fractional offset to it, sometimes you'll see one extra full second.

Haven't checked the code but pretty certain that's the reason. There's a bit more information in Convert dmesg timestamp to custom date format including a response I wrote.

Community
  • 1
  • 1
Allen Belletti
  • 331
  • 2
  • 4