This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

timestamp problems


Hello

I was working on a few scripts[1] that together profile the boot-up
process using systemtap and render an svg image very similar to
bootchart.
I noticed this strange error in timestamps that used to scramble the
XML log generated.  I had initially thought something was wrong with
my scripts and had (after a bit of complaining on my blog) managed a
workaround that problem. Now that I upgraded to F9 and I see that
error still persisting, and considering that I do nothing apart from
just calling a gettimeofday_ms(), am quite convinced that it is not a
problem with my script and even if it is.. not an obvious error that
glares at your face.
( It might also be some boot time peculiarity as when I run the
scripts after boot-up there is no such problem.)

The error:  The timestamps after a sometime  jump back by a huge number.

on Fedora 8
The timestamps starts off with something like 1220226924420
and goes on till 1220226928771
(process executing rc.sysinitentry number 133, time in ms since  first
probe : 4351 ms )
then suddenly jumps back to 1220207130000
(process executing rc.sysinit, entry number 134 )
and then continues normally till the end of the boot process.
The jump is  229.15244213 days.

( the output can be found at [2].. F8 output)


on Fedora 9
The timestamps starts with 1223857645400
and goes till 1223857652873
(process executing udev, entry number 1089, time in ms since first
probe: 7473 ms)
then jumps back to 1223837854000
( process executing udev, entry number 1090)
and then continues normally.
The jump is 229.153622685 days.

( entire output uploaded at [2] F9 output 2 with XMLs )

(the exact numbers are from one particular case.. but the trend and
order of difference is similar)


The process name or the number of entries or time elapsed before such
an event takes place is not constant but the jump is ( ~229 days in
all cases).

My **temporary** workaround:
This solution just serves my purpose and does not solve the  main
issue in anyway.

As the boot process will never last for more than a few minutes,
taking a substring (the last 7 digits) also works for me ( and works
better as then I can use them as int type ) . Luckily, the substring
is always in order resulting in proper functioning of bootlimn. But I
know this is not a solution.

Was wondering if this is a systemtap problem. I'll be grateful if
someone checks it out.

Regards
Satya Komaragiri

[1] http://code.google.com/p/bootlimn/
[2] http://code.google.com/p/bootlimn/downloads/list
project blog: http://meworkstoo.blogspot.com/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]