Re: [processor frequency]

Re: [processor frequency]

[Wolfgang Denk]

In message <005a01c614fb$2fe76b00$10eca8c0@grendel> you wrote:
> There is no "ideal" value for a given processor frequency.
> The lower the value, the less interrupt processing overhead,
> but the slower the response time to events that are detected
> or serviced during clock interrupts. 1000 HZ *may* be a sensible
> value (I have my doubts, personally) for 2+ GHz PC processors, 
> but it's excessive (IMHO) for a 200MHz processor and unworkable 
> for a 20MHz CPU. I think that 100HZ is still a reasonable value
> for an embedded RISC CPU, but the "ideal" value is going to
> be a function of the application.

We did some tests of the performance impact of 100 vs. 1000 Hz  clock
frequency on low end systems (50 MHz PowerPC); for details please see
http://www.denx.de/wiki/view/Know/Clock100vs1000Hz

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Our missions are peaceful -- not for conquest.  When we do battle, it
is only because we have no choice.
	-- Kirk, "The Squire of Gothos", stardate 2124.5

Re: [processor frequency]

[Kevin D. Kissell]

Wolfgang Denk wrote:
> In message <005a01c614fb$2fe76b00$10eca8c0@grendel> you wrote:
>> There is no "ideal" value for a given processor frequency.
>> The lower the value, the less interrupt processing overhead,
>> but the slower the response time to events that are detected
>> or serviced during clock interrupts. 1000 HZ *may* be a sensible
>> value (I have my doubts, personally) for 2+ GHz PC processors, 
>> but it's excessive (IMHO) for a 200MHz processor and unworkable 
>> for a 20MHz CPU. I think that 100HZ is still a reasonable value
>> for an embedded RISC CPU, but the "ideal" value is going to
>> be a function of the application.
> 
> We did some tests of the performance impact of 100 vs. 1000 Hz  clock
> frequency on low end systems (50 MHz PowerPC); for details please see
> http://www.denx.de/wiki/view/Know/Clock100vs1000Hz

My own results, on an SMP 2.6 kernel (as opposed to the uniprocessor
2.4 kernel used for the experiments reported) have been rather different.
Certainly the degradations I observed were far worse than the 5-10% reported
in the document you cite.  I'll try to repeat your experiment when I get
the time.

BTW, I'm puzzled by the "context switch" benchmark test results.  By what
mechanism - or by what definition of "context switch" - can having more
frequent interrupts make context switches happen more quickly?  It seems
to me that those results must be due to a systematic measurement error
being added/removed.

		Regards,

		Kevin K

RE: [processor frequency]

[Mitchell, Earl]

Wolfgang, 

In your summary you mention ...

 "This probably explains why many developers who never use low-end embedded processors don't care about (and usually don't even know of) these problems in the 2.6 kernel."

The desktop/server guys typically use much larger caches (i.e. >= 512K)
and most have L2, compared to embedded systems which typically use less
without an L2. So I'd also expect embedded guys using small caches to see 
larger decreases in performance due to more cache misses (i.e. more 
interrupts produce more evictions). 

-earlm


> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org
> [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Wolfgang Denk
> Sent: Monday, January 09, 2006 1:24 PM
> To: Kevin D. Kissell
> Cc: Sathesh Babu Edara; linux-mips@linux-mips.org
> Subject: Re: [processor frequency]
> 
> 
> In message <005a01c614fb$2fe76b00$10eca8c0@grendel> you wrote:
> > There is no "ideal" value for a given processor frequency.
> > The lower the value, the less interrupt processing overhead,
> > but the slower the response time to events that are detected
> > or serviced during clock interrupts. 1000 HZ *may* be a sensible
> > value (I have my doubts, personally) for 2+ GHz PC processors, 
> > but it's excessive (IMHO) for a 200MHz processor and unworkable 
> > for a 20MHz CPU. I think that 100HZ is still a reasonable value
> > for an embedded RISC CPU, but the "ideal" value is going to
> > be a function of the application.
> 
> We did some tests of the performance impact of 100 vs. 1000 Hz  clock
> frequency on low end systems (50 MHz PowerPC); for details please see
> http://www.denx.de/wiki/view/Know/Clock100vs1000Hz
> 
> Best regards,
> 
> Wolfgang Denk
> 
> -- 
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> Our missions are peaceful -- not for conquest.  When we do battle, it
> is only because we have no choice.
> 	-- Kirk, "The Squire of Gothos", stardate 2124.5
> 
> 

RE: [processor frequency]

[Mitchell, Earl]

Wolfgang, 

In your summary you mention ...

 "This probably explains why many developers who never use low-end embedded processors don't care about (and usually don't even know of) these problems in the 2.6 kernel."

The desktop/server guys typically use much larger caches (i.e. >= 512K)
and most have L2, compared to embedded systems which typically use less
without an L2. So I'd also expect embedded guys using small caches to see 
larger decreases in performance due to more cache misses (i.e. more 
interrupts produce more evictions). 

-earlm


> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org
> [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Wolfgang Denk
> Sent: Monday, January 09, 2006 1:24 PM
> To: Kevin D. Kissell
> Cc: Sathesh Babu Edara; linux-mips@linux-mips.org
> Subject: Re: [processor frequency]
> 
> 
> In message <005a01c614fb$2fe76b00$10eca8c0@grendel> you wrote:
> > There is no "ideal" value for a given processor frequency.
> > The lower the value, the less interrupt processing overhead,
> > but the slower the response time to events that are detected
> > or serviced during clock interrupts. 1000 HZ *may* be a sensible
> > value (I have my doubts, personally) for 2+ GHz PC processors, 
> > but it's excessive (IMHO) for a 200MHz processor and unworkable 
> > for a 20MHz CPU. I think that 100HZ is still a reasonable value
> > for an embedded RISC CPU, but the "ideal" value is going to
> > be a function of the application.
> 
> We did some tests of the performance impact of 100 vs. 1000 Hz  clock
> frequency on low end systems (50 MHz PowerPC); for details please see
> http://www.denx.de/wiki/view/Know/Clock100vs1000Hz
> 
> Best regards,
> 
> Wolfgang Denk
> 
> -- 
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> Our missions are peaceful -- not for conquest.  When we do battle, it
> is only because we have no choice.
> 	-- Kirk, "The Squire of Gothos", stardate 2124.5
> 
> 

Re: [processor frequency]

[Wolfgang Denk]

In message <43C2DB61.7090704@mips.com> you wrote:
>
> BTW, I'm puzzled by the "context switch" benchmark test results.  By what
> mechanism - or by what definition of "context switch" - can having more
> frequent interrupts make context switches happen more quickly?  It seems
> to me that those results must be due to a systematic measurement error
> being added/removed.

I have to admit that I don't have a good explanation for this either.
It's what I got with (repeated) measurements.  Cache  (flush)  issues
might  play  a  role  here - but without closer analysis this is just
speculation.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If you can't beat it or corrupt it, you pretend it was your  idea  in
the first place.                 - Terry Pratchett, _Guards! Guards!_

Re: [processor frequency]

[Wolfgang Denk]

Hello,

in message <3CB54817FDF733459B230DD27C690CEC010495E3@Exchange.MIPS.COM> you wrote:
> 
> The desktop/server guys typically use much larger caches (i.e. >= 512K)
> and most have L2, compared to embedded systems which typically use less
> without an L2. So I'd also expect embedded guys using small caches to see 
> larger decreases in performance due to more cache misses (i.e. more 
> interrupts produce more evictions). 

Corrent. FYI: the system used in my tests is a PowerPC at 50 MHz  CPU
clock with 4 kB I-Cache and 4 kB D-Cache ...

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Every program has at least one bug and can be shortened by  at  least
one instruction - from which, by induction, one can deduce that every
program can be reduced to one instruction which doesn't work.

RE: [processor frequency]

[Dominic Sweetman]

My colleague Earl writes:

> The desktop/server guys typically use much larger caches (i.e. >= 512K)
> and most have L2, compared to embedded systems which typically use less
> without an L2. So I'd also expect embedded guys using small caches to see 
> larger decreases in performance due to more cache misses (i.e. more 
> interrupts produce more evictions). 

It's certainly true that running an interrupt routine (even one which
doesn't lead to any scheduling activity) will cause some cache
traffic.  But it is important to keep the relative timescales in mind.
With an averagely bad memory system, evicting and replacing a cache
line costs 150ns read latency, with a 100ns writeback (notionally done
"in the background" just after the read) on about one miss in four...

Let's make some pessimistic assumptions.  Suppose an interrupt routine
displaces 2KB of code and data and uses 32-byte cache lines, and we
assume the process happens twice as the background process refills the
cache to its liking.  Then we'll get 120 odd reads, which will cost
about 20us, about 2% of total time on a 1KHz clock.  That doesn't
sound like it should be a huge effect.

It would be better to measure it, though.

--
Dominic Sweetman
MIPS Technologies.

RE: [processor frequency]

[Dominic Sweetman]

My colleague Earl writes:

> The desktop/server guys typically use much larger caches (i.e. >= 512K)
> and most have L2, compared to embedded systems which typically use less
> without an L2. So I'd also expect embedded guys using small caches to see 
> larger decreases in performance due to more cache misses (i.e. more 
> interrupts produce more evictions). 

It's certainly true that running an interrupt routine (even one which
doesn't lead to any scheduling activity) will cause some cache
traffic.  But it is important to keep the relative timescales in mind.
With an averagely bad memory system, evicting and replacing a cache
line costs 150ns read latency, with a 100ns writeback (notionally done
"in the background" just after the read) on about one miss in four...

Let's make some pessimistic assumptions.  Suppose an interrupt routine
displaces 2KB of code and data and uses 32-byte cache lines, and we
assume the process happens twice as the background process refills the
cache to its liking.  Then we'll get 120 odd reads, which will cost
about 20us, about 2% of total time on a 1KHz clock.  That doesn't
sound like it should be a huge effect.

It would be better to measure it, though.

--
Dominic Sweetman
MIPS Technologies.