K2.6.16.7, 1000Hz interrupts too fast?

[BarryK]

The 2.6.16 kernel has a new feature, the base interrupt rate can be adjusted.
The default was 250Hz (250 interrupts per second), but the "help" in the
kernel config program states that this setting is good for "servers".
There were only three choices, 250 was the middle one, 1000Hz the fastest.
1000Hz is described as recommended for "desktop" use, so that is what I
chose.

But, that's a base interrupt every 1millisecond, and I'm wondering how old
slow CPUs will handle that?
I do recall, for old AT-style PCs, the base hardware interrupt is every 55milliseconds -- speeding that up to 1mS would kill the PC!

I'm contemplating whether I should recompile the kernel with the 250Hz
choice.
Anyone got a thought on that?

[JustGreg]

My vote is for the 250 Hertz rate. I can understand why they might say 1000 Hertz for a desktop. If one checks the activity of a desktop system, one will see that the processor is idle for a signficant portion of the time. With a reasonable speed processor, there are more than enough processor cycles to handle the interupts from the mouse and keyboard. A server uses a lot disk input/output. The server is also responding to more network interrupts. So it would make sense to use the lower rate.

Having said the above, I doubt the user will be able to tell if the lower rate is used. So my vote is for 250 Hertz. It is better to be safe than sorry.

[Sit Heel Speak]

Linus Torvalds', Alan Cox's, and Andrew Morton's thoughts on 1000Hz can be seen in the article at:

http://kerneltrap.org/node/5411

Morton: "...some machines exhibit appreciable latency in entering low power state via ACPI, and 1000Hz reduces their battery life. By about half, iirc."

Cox: "100Hz is good for power management/older boxes, 250Hz is too fast for some laptop APM to avoid clock slew, too fast for power saving and too slow for some multimedia weenies."

Torvalds: "I chose 1000 originally partly as a way to make sure that people that assumed Hz was 100 would get a swift kick in the pants. That meant making a _big_ change, not a small subtle one...so 1kHz was a bit of an overkill, but it worked well enough that we never really got around to changing it."

In the discussion can be seen reports of failure of 2.6 on laptops, presumably due to the 1000Hz default tick, and suggestions for boot time configurability of Hz.

Perhaps if "acpi=on" is chosen as a boot time option, then Puppy could autoconfigure for 100Hz and if "acpi=off" then 1000. With an advisory message before the prompt which poses the "acpi on or off?" question. The advisory message would warn that acpi=on extends notebook battery life however some multimedia packages demand 1000Hz. I do not know what the packages are that specifically demand 1000Hz, perhaps other Puppians know.

The article also carries a link to a patch for making tick rate dynamic based on load. I am not yet a kernel programmer and so don't know what the feasibility is of implementing dynamic tick for Puppy, nor how doing so would affect acpi and other systems.

[Flash]

If Puppy2 is still in the alpha stage, why not make it 100 and see if anyone complains? Although it would be nice to be able to change it to see what it does.

[BarryK]

I gather from reading that url, that the interrupt rate is fixed, it's a config
option before compiling, and there's no boot parameter to change it, but they
are discussing the possibility in thew future.

I think I'll play safe, and stay with 100Hz, same as the 2.4 kernel.

Interesting quote from the above url:

I had to change the default Hz for my laptop (Panasonic W2) when I switched to a 2.6 kernel, because at 1000Hz, the machine would make a very annoying, high-pitched noise. At 100Hz, it emits a buzzing sound--audible but bearable. So I would be in favour of making HZ configurable, one way or another.

...yeah, I vote for the buzzing sound!

But, 100Hz choice will pay a price:

For the multimedia I do, threads MUST be awakened every 10mS. Any deviation causes too much jitter in packet processing. In 2.4.x kernels, 100Hz was too slow, because there were all too many times that the sleep would cause us to miss a whole 10mS interval, which was death to quality.

...thay do qualify that though, perhaps the improved thread handling of the
2.6 kernel will compnsate, so maybe will still get better than a 2.4 kernel
when playing video.

[Sit Heel Speak]

It looks to me like Hz is indeed configurable at boot time. I assume that "KConfigurable" means it is configurable from the KDE desktop. There is a passage in the above-referenced exchange:

[PATCH] i386: Selectable Frequency of the Timer Interrupt

...and, in a 20 June 2005 message, at

http://kerneltrap.org/node/5329

Andrew Morton said, "This summarizes my current thinking on various patches which are presently in -mm"

...quote:

pcibus_to_node and users
Will merge
CONFIG_HZ for x86 and ia64: changes default HZ to 250, make HZ Kconfigurable.
Will merge (will switch default to 1000 Hz later if that seems necessary)

Now, as far as where to get the "-mm" patches, my newbie guess would be, there's a CVS somewhere. A comment at the bottom refers to "the 2.6.12-rc3-mm2 version with reiser4" and says "This stuff is clearly ready for prime time."

For kernel-patchers out there, the dynamic-tick-rate patch is at

http://lwn.net/Articles/138264/

and an explanation of it is at

http://lwn.net/Articles/138969/

I gather that smooth DVD playback is the criterion by which is judged, whether variable tick rate is acceptable. At the bottom of this latter article is the comment,

"At the moment a $50 TV with a $30 DVD player can achieve smoother DVD playback than Linux on a 2GHz workstation. Pathetic." But it is not clear from the posting, whether the poster had actually _tried_ the dynamic tick rate patch.

[atchbo]

Does this tick rate therefore prevent the CPU from idling or throttling back? My Averatec 6210 runs extremely hot with Puppy and none of the thermal monitors or ACPI stuff seems to help. It seems that the CPU runs constantly, and I'm wondering if this interrupt tick rate could be the culprit.

Does it sound likely that this is the case?


Cheers,
Atchbo