[PATCH] HZ: 300Hz support

[PATCH] HZ: 300Hz support

[Alan Cox]

Fix two things. Firstly the unit is "Hz" not "HZ". Secondly it is useful
to have 300Hz support when doing multimedia work. 250 is fine for us in
Europe but the US frame rate is 30fps (29.99 blah for pedants). 300
gives us a tick divisible by both 25 and 30, and for interlace work 50
and 60. It's also giving similar performance to 250Hz.

I'd argue we should remove 250 and add 300, but that might be excess
disruption for now.

Signed-off-by: Alan Cox <alan@redhat.com>

diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.19-rc4-mm1/kernel/Kconfig.hz
linux-2.6.19-rc4-mm1/kernel/Kconfig.hz
--- linux.vanilla-2.6.19-rc4-mm1/kernel/Kconfig.hz	2006-10-31
15:40:54.000000000 +0000
+++ linux-2.6.19-rc4-mm1/kernel/Kconfig.hz	2006-11-08 17:06:38.000000000
+0000
@@ -7,7 +7,7 @@
 	default HZ_250
 	help
 	 Allows the configuration of the timer frequency. It is customary
-	 to have the timer interrupt run at 1000 HZ but 100 HZ may be more
+	 to have the timer interrupt run at 1000 Hz but 100 Hz may be more
 	 beneficial for servers and NUMA systems that do not need to have
 	 a fast response for user interaction and that may experience bus
 	 contention and cacheline bounces as a result of timer interrupts.
@@ -19,21 +19,30 @@
 	config HZ_100
 		bool "100 HZ"
 	help
-	  100 HZ is a typical choice for servers, SMP and NUMA systems
+	  100 Hz is a typical choice for servers, SMP and NUMA systems
 	  with lots of processors that may show reduced performance if
 	  too many timer interrupts are occurring.
 
 	config HZ_250
 		bool "250 HZ"
 	help
-	 250 HZ is a good compromise choice allowing server performance
+	 250 Hz is a good compromise choice allowing server performance
 	 while also showing good interactive responsiveness even
-	 on SMP and NUMA systems.
+	 on SMP and NUMA systems. If you are going to be using NTSC video
+	 or multimedia, selected 300Hz instead.
+
+	config HZ_300
+		bool "300 HZ"
+	help
+	 300 Hz is a good compromise choice allowing server performance
+	 while also showing good interactive responsiveness even
+	 on SMP and NUMA systems and exactly dividing by both PAL and
+	 NTSC frame rates for video and multimedia work.
 
 	config HZ_1000
 		bool "1000 HZ"
 	help
-	 1000 HZ is the preferred choice for desktop systems and other
+	 1000 Hz is the preferred choice for desktop systems and other
 	 systems requiring fast interactive responses to events.
 
 endchoice
@@ -42,5 +51,6 @@
 	int
 	default 100 if HZ_100
 	default 250 if HZ_250
+	default 300 if HZ_300
 	default 1000 if HZ_1000
 

 

Re: [PATCH] HZ: 300Hz support

[Arjan van de Ven]

On Wed, 2006-11-08 at 20:42 +0000, Alan Cox wrote:
> Fix two things. Firstly the unit is "Hz" not "HZ". Secondly it is useful
> to have 300Hz support when doing multimedia work. 250 is fine for us in
> Europe but the US frame rate is 30fps (29.99 blah for pedants). 300
> gives us a tick divisible by both 25 and 30, and for interlace work 50
> and 60. It's also giving similar performance to 250Hz.
> 
> I'd argue we should remove 250 and add 300, but that might be excess
> disruption for now.


the last time 300 was proposed the counter argument was that it was
lousy in terms of PIT rounding... did you check that out?

Re: [PATCH] HZ: 300Hz support

[Alan Cox]

Ar Mer, 2006-11-08 am 21:48 +0100, ysgrifennodd Arjan van de Ven:
> > I'd argue we should remove 250 and add 300, but that might be excess
> > disruption for now.
> 
> 
> the last time 300 was proposed the counter argument was that it was
> lousy in terms of PIT rounding... did you check that out?

It keeps time better than 250 when I tried it. It is not perfect but
then the PIT runs at a stupid rate so any choice is a little bit off. I
think there might be a better argument anyway for making HZ fixed at
1000 and adding a boot time parameter/sysctl value which is a "ticks
divisor", so on a server you can do

	echo "10" >/proc/sys/tick_granularity

and jiffies bumps in 10s 1/10th as often. That needs someone who
understands the maths and the behaviour of the time slew and xntp stuff
to do the job right though, and that isn't me.

Alan

Re: [PATCH] HZ: 300Hz support

[Jiri Slaby]

Alan Cox wrote:
> Fix two things. Firstly the unit is "Hz" not "HZ". Secondly it is useful
> to have 300Hz support when doing multimedia work. 250 is fine for us in
> Europe but the US frame rate is 30fps (29.99 blah for pedants). 300
> gives us a tick divisible by both 25 and 30, and for interlace work 50
> and 60. It's also giving similar performance to 250Hz.
> 
> I'd argue we should remove 250 and add 300, but that might be excess
> disruption for now.
> 
> Signed-off-by: Alan Cox <alan@redhat.com>
> 
> diff -u --new-file --recursive --exclude-from /usr/src/exclude
> linux.vanilla-2.6.19-rc4-mm1/kernel/Kconfig.hz
> linux-2.6.19-rc4-mm1/kernel/Kconfig.hz
> --- linux.vanilla-2.6.19-rc4-mm1/kernel/Kconfig.hz	2006-10-31
> 15:40:54.000000000 +0000
> +++ linux-2.6.19-rc4-mm1/kernel/Kconfig.hz	2006-11-08 17:06:38.000000000
> +0000
> @@ -7,7 +7,7 @@
>  	default HZ_250
>  	help
>  	 Allows the configuration of the timer frequency. It is customary
> -	 to have the timer interrupt run at 1000 HZ but 100 HZ may be more
> +	 to have the timer interrupt run at 1000 Hz but 100 Hz may be more
>  	 beneficial for servers and NUMA systems that do not need to have
>  	 a fast response for user interaction and that may experience bus
>  	 contention and cacheline bounces as a result of timer interrupts.
> @@ -19,21 +19,30 @@
>  	config HZ_100
>  		bool "100 HZ"
[...]
>  	config HZ_250
>  		bool "250 HZ"
[...]
> +	config HZ_300
> +		bool "300 HZ"
[...]
>  	config HZ_1000
>  		bool "1000 HZ"

Shouldn't be these also changed (I mean those in quotes)?

regards,
-- 
http://www.fi.muni.cz/~xslaby/            Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

Re: [PATCH] HZ: 300Hz support

[Willy Tarreau]

On Wed, Nov 08, 2006 at 08:42:37PM +0000, Alan Cox wrote:
> Fix two things. Firstly the unit is "Hz" not "HZ". Secondly it is useful
> to have 300Hz support when doing multimedia work. 250 is fine for us in
> Europe but the US frame rate is 30fps (29.99 blah for pedants). 300
> gives us a tick divisible by both 25 and 30, and for interlace work 50
> and 60. It's also giving similar performance to 250Hz.
> 
> I'd argue we should remove 250 and add 300, but that might be excess
> disruption for now.

I'd like to keep 250 for a simple reason : the period is an integer
number of milliseconds. I find it very convenient to be able to convert
jiffies to ms. It serves at several places, for instance, poll(). In
fact, what I like with 250 is that there is no divide between ms and
jiffies, but just a bit shift.

Regards,
Willy

Re: [PATCH] HZ: 300Hz support

[Andi Kleen]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> Fix two things. Firstly the unit is "Hz" not "HZ". Secondly it is useful
> to have 300Hz support when doing multimedia work. 250 is fine for us in
> Europe but the US frame rate is 30fps (29.99 blah for pedants). 300
> gives us a tick divisible by both 25 and 30, and for interlace work 50
> and 60. It's also giving similar performance to 250Hz.
> 
> I'd argue we should remove 250 and add 300, but that might be excess
> disruption for now.

If we go down that path I would like to have 256.

Why? There are still lots of systems with broken Interrupt 0 routing
and usually on those the RTC works just fine. But unfortunately RTC
can be only programmed to power of two frequencies. 256 would fit.

-Andi

Re: [PATCH] HZ: 300Hz support

[Jan Engelhardt]

>> Fix two things. Firstly the unit is "Hz" not "HZ". Secondly it is useful
>> to have 300Hz support when doing multimedia work. 250 is fine for us in
>> Europe but the US frame rate is 30fps (29.99 blah for pedants). 300
>> gives us a tick divisible by both 25 and 30, and for interlace work 50
>> and 60. It's also giving similar performance to 250Hz.
>> 
>> I'd argue we should remove 250 and add 300, but that might be excess
>> disruption for now.
>
>If we go down that path I would like to have 256.

Before we have tons of choosable HZ possibilities, I prefer 
http://lkml.org/lkml/2006/6/18/111 where the user can input his desired 
value.

>Why? There are still lots of systems with broken Interrupt 0 routing
>and usually on those the RTC works just fine. But unfortunately RTC
>can be only programmed to power of two frequencies. 256 would fit.


	-`J'
--