Re: test time-warps [was: Re: 2.6.14-rt13]

[Fernando Lopez-Lezcano]

On Mon, 2005-11-21 at 23:19 +0100, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx> wrote:
> 
> > On Tue, 2005-11-15 at 10:08 +0100, Ingo Molnar wrote:
> > > i have released the 2.6.14-rt13 tree, which can be downloaded from the 
> > > usual place:
> > > 
> > >    http://redhat.com/~mingo/realtime-preempt/
> > > 
> > > lots of fixes in this release affecting all supported architectures, all 
> > > across the board. Big MIPS update from John Cooper.
> > 
> > Can someone tell me if 2.6.14-rt13 is supposed to be fixed re: the 
> > problems I was having with random screensaver triggering and keyboard 
> > repeats?
> > 
> > It is apparently not fixed.
> > 
> > I just had a short burst of key repeats and saw one random screen 
> > blank. Right now everything seems normal but I was not allucinating 
> > :-)
> 
> is this on the dual-core X2 box, running 32-bit code? 

That's correct. 

> Did it happen with idle=poll? 

No, I'm not running with idle=poll right now.

> Without idle=poll the TSCs run apart and a number of 
> artifacts may happen. With idle=poll specified the TSC _should_ be fully 
> synchronized.

Well, I could try but it is not a solution I could use. It would turn
all my machines into space heaters 24x7, no sense in doing that :-)

I got an answer off the list from John (Stultz) in response to the dmesg
output I sent him and he suggested I try idle=poll (which I briefly did
last week) and also changing:
  /sys/devices/system/clocksource/clocksource0/clocksource
to acpi_pm, which I just did. It is too early to tell re: keyboard
repeats and screensaver false triggers, but it did fix the problems I
was seeing with a hacked Jack that is using gettimeofday instead of tsc
reads. Meaning, Jack with gettimeofday + tsc timing source has problems,
Jack with gettimeofday + acpi_pm does not. It would seem gettimeofday is
not working correctly with tsc. 

> To make sure could you run the attached time-warp-test utility i wrote 
> today? 

I will and report back.
Thanks.
-- Fernando


> Compile it with:
> 
>   gcc -Wall -O2 -o time-warp-test time-warp-test.c
> 
> it detects and reports time-warps (and does a maximum search for them 
> over time, that way you can see systematic drifts too). (It auto-detects 
> the # of CPUs and runs the appropriate number of tasks.)
> 
> running this tool on a X2 with idle=poll and an -rt kernel should give a 
> silent test-output.
> 
> running a vanilla kernel should give TSC level time warps:
> 
>  #CPUs: 2
>  running 2 tasks to check for time-warps.
>  warp ..        -1 cycles, ... 00000277ed9520c6 -> 00000277ed9520c5 ?
>  warp ..       -18 cycles, ... 00000277ed97ac77 -> 00000277ed97ac65 ?
>  warp ..       -19 cycles, ... 00000277edaedd54 -> 00000277edaedd41 ?
>  warp ..       -84 cycles, ... 00000277ede0558a -> 00000277ede05536 ?
>  warp ..       -97 cycles, ... 00000278035328a5 -> 0000027803532844 ?
>  warp ..      -224 cycles, ... 000002781ed2db04 -> 000002781ed2da24 ?
> 
> (because the vanilla kernel doesnt do TSC synchronization accurately)
> 
> running it without idle=poll should give some really big time warps:
> 
>  neptune:~> ./time-warp-test
>  #CPUs: 2
>  running 2 tasks to check for time-warps.
>  warp ..   -435934 cycles, ... 00000101a2db4a8f -> 00000101a2d4a3b1 ?
>  WARP ..      -123 usecs, .... 0003e96c2f3bb579 -> 0003e96c2f3bb4fe ?
>  WARP ..      -198 usecs, .... 0003e96c2f3bb625 -> 0003e96c2f3bb55f ?
>  WARP ..      -199 usecs, .... 0003e96c2f3bb659 -> 0003e96c2f3bb592 ?
>  warp ..   -436117 cycles, ... 00000101a2e5aaf0 -> 00000101a2df035b ?
>  warp ..   -437143 cycles, ... 00000101a2e84590 -> 00000101a2e199f9 ?
>  warp ..   -437314 cycles, ... 00000101a2ead1b1 -> 00000101a2e4256f ?
>  warp ..   -437363 cycles, ... 00000101a2ed9b19 -> 00000101a2e6eea6 ?
>  WARP ..  -1951680 usecs, .... 0003e96c2f597f70 -> 0003e96c2f3bb7b0 ?
>  WARP ..  -1951879 usecs, .... 0003e96c2f598016 -> 0003e96c2f3bb78f ?
>  WARP ..  -1951681 usecs, .... 0003e96c2f598014 -> 0003e96c2f3bb853 ?
>  warp ..   -437365 cycles, ... 00000101a4c5be7b -> 00000101a4bf1206 ?
>  warp ..   -437366 cycles, ... 00000101a8f4af76 -> 00000101a8ee0300 ?
>  warp ..   -437367 cycles, ... 00000101a968a34a -> 00000101a961f6d3 ?
> 
> these time warps will get worse over time - as the two cores drift 
> apart. (note that they wont drift during the test itself, because the 
> test makes all cores artificially busy and the X2 TSC drifting depends 
> on the core being idle)
> 
> but in any case, -rt13 should be silent and there should be no time 
> warps. If there are any then those could cause the keyboard repeat 
> problems.
> 
> 	Ingo
> 
> -------{ CUT HERE time-warp-test.c }-------------->
[MUNCH]


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/