lkml.org 
[lkml]   [2005]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRE: [PATCH] optimize writer path in time_interpolator_get_counter()
On Tue, 2 Aug 2005, Luck, Tony wrote:

> Yes this is an SMP system (Intel Tiger4). Cpu0 is the boot cpu, and is
> indeed the one that takes the write lock, and thus the fast-return from
> the get_counter() code. I'm just very confused as to why I only see these
> 10X worse outliers on cpu3. There doesn't seem to be anything special
> about it (/proc/interrupts shows similar stuff happening on each cpu).

Are you sure that this is not some hardware contingency? I.e. cachelines
are prioritized according to cpu number or some such thing? Switch the
timer interrupt to a different cpu and see how this affects the
situation.

> >We can still switch on the nojitter by default if the ITC's are guaranteed
> >to be properly synchronized which will make all this ugliness go away.
>
> What do you mean by "properly synchronized"? We can't get them
> completely in step ... but we do know that they are very close.

Properly synchronized means completely in step.

> Closer than the microsecond granularity that most users (gettimeofday)
> are going to pass back to the caller. But running with "nojitter" will
> occasionally result in time (as seen on two different processors) sometimes
> jumping back by a microsecond. How bad is this in practice? I can
> see that a user that simply subtracts two times may sometimes see an
> answer of minus one micro-second ... but does this hurt?

In practice we have seen the time jump forward to A.D. 2587 which then
results in tcp retransmits periods of a few centuries. I'd strongly advise
against nojitter unless you know that the ITCs are in step. Isnt the
hardware capable of making them run in step? It seems that some i386
BIOSes have accomplished just that.

Note that the time subsystem for ia64 is not based on microseconds like
i386 but on nanoseconds. clock_gettime will return nanosecond resolution
which WILL become negative with devastating consequence if the clock
jumps back a microsecond. A single ia64 processor can do multiple calls
to retrieve time from user space within a microsecond.

The jitter compensation avoids the problems arising with time for ITC.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-08-03 00:12    [W:0.032 / U:1.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site