Re: Out of order timings of gettimeofday_us()

["Alan D. Brunelle" <alan dot brunelle at hp dot com>]

Frank Ch. Eigler wrote:
> "Nathan A. Debardeleben" <ndebard@lanl.gov> writes:
>
>   
> > I have a very simple script which seems to demonstrate time values
> > coming out of gettimeofday_us() being out of order.  [...]  Is the
> > us() timing just too fine grained?  If it's acting like this here I
> > question its values in other places.
> >     
>
> In the absence of another suitable kernel facility, systemtap's
> timestamping functions use the CPU TSC.  If there is more than one
> CPU, they have imperfect TSC synchronization, and if a task gets moved
> between CPUs between the moments you are taking a snapshot, then this
> sort of thing would be expected.  Does this resemble your scenario?
>
> - FChE
>   
The blktrace kernel component attempts to overcome some of this with 
periodic synchronization across the CPUs. (see block/blktrace.c for 
details).

Notwithstanding the effort put into getting that to work, I still find 
under certain heavy loads time still goes backwards under blktrace. One 
could use the functionality in blktrace as a starting point, perhaps it 
would make things better for SystemTAP.

One last thing, I seem to recall there were other issues when doing 
timings in a multicore CPU environment, but off the top of my head I can 
not recollect what they were... (old age...)

Alan