From: Jonathan Woithe <jwoithe@physics.adelaide.edu.au>
Message-Id: <200512090019.jB90JSZ5030763@auster.physics.adelaide.edu.au>
Subject: Re: 2.6.14-rt21: slow-running clock
To: johnstul@us.ibm.com (john stultz)
Date: Fri, 9 Dec 2005 10:49:27 +1030 (CST)
Cc: jwoithe@physics.adelaide.edu.au (Jonathan Woithe),
       linux-kernel@vger.kernel.org
In-Reply-To: <1134012141.10613.81.camel@cog.beaverton.ibm.com> from "john stultz" at Dec 07, 2005 07:22:21 PM
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2112
Lines: 41

John

> > > > I'm also wondering whether this might be related to one other thing I
> > > > noticed a week or so back (also reported to the list, but thus far no
> > > > followups). If I enabled the (new) "High resolution timers" feature (as
> > > > distinct from HPET), things like /usr/bin/sleep run for far longer than
> > > > they should irrespective of machine load.  For example, "sleep 1" from bash
> > > > actually delays 38 seconds, not 1 second as expected.
> > > 
> > > Does disabling the "High resolution timers" feature change the behavior
> > > all?
> > 
> > I should clarify.  Everything I've given you thus far has been with the
> > "high resolution timers" feature disabled.  Two or so weeks ago I tried
> > enabling it and that's when "sleep 1" took 38 seconds to complete. 
> > Disabling "high resoltion timers" at least made "sleep 1" behave somewhat
> > saner.  I don't know if having the high res timers enabled affects the
> > accuracy of the system clock however.  I'll test this tonight.

Some further information.  Today I enabled the Hi res timer option in
2.6.14-rt21 with a resolution of 10000ns and did a full recompile.  Under
this kernel "sleep 1" did the right thing.  The slowdown in the c3tsc
clocksource and its selection ahead of more capable timers was still the
same in this kernel - in other words, enabling the hi res timer does not
change things.

I then changed the resolution to 1000ns (the default) and recompiled.  This
is the setting I used previously, but this time around "sleep 1" behaved
itself (c3tsc still ran slow though).  Thus for the moment it seems that the
sleep misbehaviour may have been due to some transient problem with the
configure system.  I'll test again once we've sorted out the c3tsc thing,
but it seems possible at this stage that the long "sleep" thing is not a bug
as such.

Regards
  jonathan
-
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/