[-rt] time-related problems with CPU frequency scaling

[-rt] time-related problems with CPU frequency scaling

[Wolfgang Hoffmann]

First of all a big thank you for your great work on the -rt patchset.
I'm running 2.6.16-rt16 on a Pentium-M based machine, and basically it runs 
fine, as long as I disable speedstep.

Now with speedstep enabled and CONFIG_HIGH_RES_TIMERS=y, I see some anomalies:
- time-of-day lags gradually behind wallclock time
- if CPU frequency is low when jackd is started, it complains:
    "delay of 2915.000 usecs exceeds estimated spare
    time of 2847.000; restart ..."
  as soon as frequency is scaled up. Seems that jackd gets confused by some
  influence of CPU frequency on timekeeping? No problems as long as CPU
  frequency isn't scaled up, though.
- values in /proc/sys/kernel/preempt_max_latency scales inverse to
    CPU frequency, i.e. 24us with CPU @ 800MHz and 12us with CPU @ 1,6GHz

Are my speedstep-problems known issues? If so, is there work going on to 
address these? Or is it generally not recommended to run -rt with active 
speedstep?

To see if it makes a difference, I tried CONFIG_HIGH_RES_TIMERS=n, but then I 
run into deeper troubles, caused by the softirq-timer/0 kernel thread. If I 
leave it at it's default priority of FIFO 1, high-prio threads don't wake up 
from sleep() as long as mid-prio theads preempt softirq-timer/0. If I boost 
softirq-timer/0 priority (as suggested on various places on the net), I'm 
getting bad latencies (> 40 ms) every 10 minutes due to some routing-related 
action (rt_secret_rebuild) being run by softirq-timer/0.

So I switched back to CONFIG_HIGH_RES_TIMERS=y, since softirq-timer/0 can be 
left at low priority and wakeup from sleep() seems to work fine.

Btw, is there any documentation on what's run in the various kernel threads? 
It would be very helpful for adjusting the priority setup.

Wolfgang

Re: [-rt] time-related problems with CPU frequency scaling

[Lee Revell]

On Sun, 2006-04-16 at 20:41 +0200, Wolfgang Hoffmann wrote:
> - if CPU frequency is low when jackd is started, it complains:
>     "delay of 2915.000 usecs exceeds estimated spare
>     time of 2847.000; restart ..."
>   as soon as frequency is scaled up. Seems that jackd gets confused by some
>   influence of CPU frequency on timekeeping? No problems as long as CPU
>   frequency isn't scaled up, though.

JACK still uses the TSC for timing and thus is incompatible with CPU
frequency scaling.  You must use the -clockfix branch from CVS.

> - values in /proc/sys/kernel/preempt_max_latency scales inverse to
>     CPU frequency, i.e. 24us with CPU @ 800MHz and 12us with CPU @ 1,6GHz 

This is normal - code that takes 12us to run at 1.6 GHz will take 24us
at 800MHz.  TANSTAAFL ;-)

Lee

Re: [-rt] time-related problems with CPU frequency scaling

[Wolfgang Hoffmann]

On Tuesday 18 April 2006 00:35, Lee Revell wrote:
> On Sun, 2006-04-16 at 20:41 +0200, Wolfgang Hoffmann wrote:
> > - if CPU frequency is low when jackd is started, it complains:
> >     "delay of 2915.000 usecs exceeds estimated spare
> >     time of 2847.000; restart ..."
> >   as soon as frequency is scaled up. Seems that jackd gets confused by
> > some influence of CPU frequency on timekeeping? No problems as long as
> > CPU frequency isn't scaled up, though.
>
> JACK still uses the TSC for timing and thus is incompatible with CPU
> frequency scaling.  You must use the -clockfix branch from CVS.

Ok, so that's a userspace issue? Thanks for the pointer, I'll try the CVS 
branch.

> > - values in /proc/sys/kernel/preempt_max_latency scales inverse to
> >     CPU frequency, i.e. 24us with CPU @ 800MHz and 12us with CPU @ 1,6GHz
>
> This is normal - code that takes 12us to run at 1.6 GHz will take 24us
> at 800MHz.  TANSTAAFL ;-)

So I misunderstood preempt_max_latency. I thought it to be absolute time, but 
it actually is codepath cycles, translated to microseconds using the current 
CPU frequency. Thanks for clarifying. 

Wolfgang

Re: [-rt] time-related problems with CPU frequency scaling

[Lee Revell]

On Tue, 2006-04-18 at 08:11 +0200, Wolfgang Hoffmann wrote:
> So I misunderstood preempt_max_latency. I thought it to be absolute
> time, but it actually is codepath cycles, translated to microseconds
> using the current CPU frequency. Thanks for clarifying.  

They are one and the same.  At 800Mhz the same code patch causes twice
the latency.

Lee

Re: [-rt] time-related problems with CPU frequency scaling

[Wolfgang Hoffmann]

On Sunday 16 April 2006 20:41, Wolfgang Hoffmann wrote:
> Now with speedstep enabled and CONFIG_HIGH_RES_TIMERS=y, I see some
> anomalies:
> - time-of-day lags gradually behind wallclock time

It turns out that this is a non-issue. I can't quite explain how I came to the 
impression that there is a clock lag, but current status is that the clock 
runs correctly. So sorry for the noise.

On Tuesday 18 April 2006 00:35, Lee Revell wrote:
> On Sun, 2006-04-16 at 20:41 +0200, Wolfgang Hoffmann wrote:
> > - if CPU frequency is low when jackd is started, it complains:
> >     "delay of 2915.000 usecs exceeds estimated spare
> >     time of 2847.000; restart ..."
> >   as soon as frequency is scaled up. Seems that jackd gets confused by
> > some influence of CPU frequency on timekeeping? No problems as long as
> > CPU frequency isn't scaled up, though.
>
> JACK still uses the TSC for timing and thus is incompatible with CPU
> frequency scaling.  You must use the -clockfix branch from CVS.

Thanks for the pointer, Lee. I'm now running the clockfix CVS branch and the 
problems are solved. So the -rt kernel is fine.

Thanks for the help,
Wolfgang