I just installed gento-sources 2.4.19-r7 today. (i was using a 2.4.19-pre2 from kernel.org).

First thing I noticed was that two of my dockapps were going crazy fast: wmfire and wmfrontier. wmfire draws some nice flames whose height is proportional to cpu usage. wmfrontier draws a starship with a bunch of stars flying by.

well suddenly the flames were REALLY fast and the stars were flying by way faster than before (I'd say about 10 times faster)

so I pulled up the wmfrontier source, and saw that the event loop had a usleep(3) call in it. I cranked up the amount of time in the sleep and it made little difference.

I remembered seeing a kernel config option to set the value of Hz which controls how many jiffies fire per second. The default was 1000. I was thinking that the normal setting for this was 100, and that you normally don't get to change it at configure time, but have to go hacking in the code. a quick google found that yes, it is normally 100 for x86.

So i set it to 100, recompiled and rebooted, and my starship was doing a nice sedate warp 1 rather than warp 10. back the way it's been for as long as I'd been running the silly thing.

I'm curious: why would one want to tweak the jiffy, and why is the default 1000 instead of 100 like it is in the plain kernel?

The current development kernel remains 2.5.24. Linus has not released any kernels - or surfaced on the linux-kernel mailing list - since before OLS and the Kernel Summit. Some patches are beginning to show up in his BitKeeper tree, however; they include some SCSI updates, an NTFS update, and, interestingly, a change of the internal x86 clock frequency to 1000 Hz.

Tweaking the jiffy is helpful because 100 Hz is a really old number; on 1.0 GHz machine, each process would get roughly 10 million processor cycles before being interrupted. That seems excessive, and the theory was that latency and responsiveness could be improved by taking 100 Hz and making it 1000 Hz. Numbers are still coming in, but it hasn't hurt anything and scheduling processes ten times faster can only increase throughput.

I just realized that since he used an '80' that would make it run about 12500 times per second!! I think the scheduler just didn't have enough resolution to get it to run that often, but with the extra resolution provided by the '1000' it got a lot closer. so I'm compiling the kernel now with '1000' again and i'll try to tweak the usleep until it runs about 30 times per second instead.