12 Jul
2005
12 Jul
'05
6:35 p.m.
Lee Revell <rlrevell(a)joe-job.com>
On Tue, 2005-07-12 at 20:57 +0200, Kjetil Svalastog
Matheussen wrote:
The program use poll to sleep. If the resolution of the kernel is 100Hz,
there
would sometimes be a too long delay of up to 10ms (and probably beyond)
before the program is woken up, and before a midi message is sent,
which can cause music to stutter.
Simple as that. :-)
E-radium has been tested with both the 2.4 kernel
and the 2.6 kernel
and with a ~1GhZ machine and a ~2ghz machine. (A 2.4 kernel with a
100hz resolution timer will proably not work very nice though.)
Can you please explain why 100HZ would be a problem for your app? Right
now the kernel people are trying to change the default HZ for 2.6 to
250. I have told them that this is insane but they seem inclined to do
it anyway.
If you can provide more examples of apps that would be
broken by this
change maybe we can convince them not to change it.
Hmm, mplayer I guess...
Don't know how muse, rosegarden, seq24 etc. handles timing...
But all midi-sequencers that doesn't use /dev/rtc could suffer. (?)
12 Jul
12 Jul
9:03 p.m.
On Tue, 12 Jul 2005 22:35:24 +0200 (CEST)
"Kjetil Svalastog Matheussen
<k.s.matheussen(a)notam02.no>" <k.s.matheussen(a)notam02.no> wrote:
Some semieducated blabbering ahead (might be all wrong):
I think i once read that interrupt handling "short circuits" the linux
scheduler (in the sense that not only at every timer interrupt but also
at the end of finishing any interrupt handler the kernel looks which
processes are ready to run etc. and maybe there's a high prio process
waiting just for that interrupt (by i.e. polling or reading on a device
file).
So for all those realtime processes that depend on events that are
triggering interrupts (like soundcards' irqs) the timer interrupt really
doesn't matter. I'm not sure at all though this applies to midi handling
(and especially to alsa_seq when routing from one app to another) or is
even correct in any sense at all :)
Anyone can shed light?
Regards,
Florian Schmidt
--
Palimm Palimm!
http://affenbande.org/~tapas/
Can you please
explain why 100HZ would be a problem for your app? Right
now the kernel people are trying to change the default HZ for 2.6 to
250. I have told them that this is insane but they seem inclined to do
it anyway.
The program use poll to sleep. If the resolution of the kernel is 100Hz,
there
would sometimes be a too long delay of up to 10ms (and probably beyond)
before the program is woken up, and before a midi message is sent,
which can cause music to stutter.
Simple as that. :-) 
9:34 p.m.
On Wed, 2005-07-13 at 01:03 +0200, Florian Schmidt wrote:
Some semieducated blabbering ahead (might be all
wrong):
I think i once read that interrupt handling "short circuits" the linux
scheduler (in the sense that not only at every timer interrupt but also
at the end of finishing any interrupt handler the kernel looks which
processes are ready to run etc. and maybe there's a high prio process
waiting just for that interrupt (by i.e. polling or reading on a device
file).
So for all those realtime processes that depend on events that are
triggering interrupts (like soundcards' irqs) the timer interrupt really
doesn't matter. I'm not sure at all though this applies to midi handling
(and especially to alsa_seq when routing from one app to another) or is
even correct in any sense at all :)
Anyone can shed light?
Correct, it's not an issue for apps driven by hardware interrupts like
JACK, because the sound card consumes data at a constant rate. But for
MIDI or video where you have to periodically push data to the device it
matters.
Lee
13 Jul
13 Jul
12:49 p.m.
On Tue, Jul 12, 2005 at 07:34:07PM -0400, Lee Revell wrote:
On Wed, 2005-07-13 at 01:03 +0200, Florian Schmidt
wrote:
What is driving the kernel-devs to regress on this issue?
--
Eric Dantan Rzewnicki | Systems Administrator
Technical Operations Division | Radio Free Asia
2025 M Street, NW | Washington, DC 20036 | 202-530-4900
CONFIDENTIAL COMMUNICATION
This e-mail message is intended only for the use of the addressee and
may contain information that is privileged and confidential. Any
unauthorized dissemination, distribution, or copying is strictly
prohibited. If you receive this transmission in error, please contact
network(a)rfa.org.
Some semieducated blabbering ahead (might be all
wrong):
I think i once read that interrupt handling "short circuits" the linux
scheduler (in the sense that not only at every timer interrupt but also
at the end of finishing any interrupt handler the kernel looks which
processes are ready to run etc. and maybe there's a high prio process
waiting just for that interrupt (by i.e. polling or reading on a device
file).
So for all those realtime processes that depend on events that are
triggering interrupts (like soundcards' irqs) the timer interrupt really
doesn't matter. I'm not sure at all though this applies to midi handling
(and especially to alsa_seq when routing from one app to another) or is
even correct in any sense at all :)
Anyone can shed light?
Correct, it's not an issue for apps driven by hardware
interrupts like
JACK, because the sound card consumes data at a constant rate. But for
MIDI or video where you have to periodically push data to the device it
matters.
2:31 p.m.
On Wed, 13 Jul 2005 10:49:11 -0400
Eric Dantan Rzewnicki <rzewnickie(a)rfa.org> wrote:
Well, i suppose it's a tradeoff between throughput and responsiveness.
Larger timeslices increase system throughput (less time is spent in the
scheduler) while smaller timeslices increase responsiveness.
Flo
--
Palimm Palimm!
http://affenbande.org/~tapas/
Correct,
it's not an issue for apps driven by hardware interrupts like
JACK, because the sound card consumes data at a constant rate. But for
MIDI or video where you have to periodically push data to the device it
matters.
What is driving the kernel-devs to regress on this issue?
2:44 p.m.
On Wed, Jul 13, 2005 at 06:31:21PM +0200, Florian Schmidt wrote:
On Wed, 13 Jul 2005 10:49:11 -0400
Eric Dantan Rzewnicki <rzewnickie(a)rfa.org> wrote:
Well, i
suppose it's a tradeoff between throughput and responsiveness.
Larger timeslices increase system throughput (less time is spent in the
scheduler) while smaller timeslices increase responsiveness.
I expected something like this. But, I guess my question was more, who
is complaining about HZ=1024? To which I guess the answer would be
everyone who is more concerned about throughput than latency. Though,
somehow I think that everyone needs a good balance between the two.
--
Eric Dantan Rzewnicki | Systems Administrator
Technical Operations Division | Radio Free Asia
2025 M Street, NW | Washington, DC 20036 | 202-530-4900
CONFIDENTIAL COMMUNICATION
This e-mail message is intended only for the use of the addressee and
may contain information that is privileged and confidential. Any
unauthorized dissemination, distribution, or copying is strictly
prohibited. If you receive this transmission in error, please contact
network(a)rfa.org.
Correct,
it's not an issue for apps driven by hardware interrupts like
JACK, because the sound card consumes data at a constant rate. But for
MIDI or video where you have to periodically push data to the device it
matters.
What is driving the kernel-devs to regress on this issue?
8:01 p.m.
On Wed, 13 Jul 2005 12:44:32 -0400
Eric Dantan Rzewnicki <rzewnickie(a)rfa.org> wrote:
I expected something like this. But, I guess my
question was more, who
is complaining about HZ=1024? To which I guess the answer would be
everyone who is more concerned about throughput than latency. Though,
somehow I think that everyone needs a good balance between the two.
I suppose to make everyone happy this should be runtime configurable.
Incorporating which would be quite a task :)
Regards,
Florian Schmidt
--
Palimm Palimm!
http://affenbande.org/~tapas/
3:27 p.m.
On Wed, 2005-07-13 at 18:31 +0200, Florian Schmidt wrote:
On Wed, 13 Jul 2005 10:49:11 -0400
Eric Dantan Rzewnicki <rzewnickie(a)rfa.org> wrote:
Well, i suppose it's a tradeoff between throughput and responsiveness.
Larger timeslices increase system throughput (less time is spent in the
scheduler) while smaller timeslices increase responsiveness.
Someone proposed HZ=864 which might be OK.
Can someone tell me what the minimum HZ you would need to send MIDI
clock or MTC would be? I think this is a good place to draw the line.
Lee
Correct,
it's not an issue for apps driven by hardware interrupts like
JACK, because the sound card consumes data at a constant rate. But for
MIDI or video where you have to periodically push data to the device it
matters.
What is driving the kernel-devs to regress on this issue? 
5:42 p.m.
On Wed, 2005-07-13 at 10:27, Lee Revell wrote:
On Wed, 2005-07-13 at 18:31 +0200, Florian Schmidt
wrote:
The midi bit rate is 31250, midi bytes are 10 bits long (8 data bits, 1
start bit, 1 stop bit or so I seem to remember), so that'd be .32 msec
per byte. A note on command without running status would take 3 bytes,
or 0.96 msec, or approx one millisecond.
MTC (Midi Time Code) critical messages are the Quarter Frame messages,
which are two bytes long. So, 0.64 msec long.
Midi Clock messages (a completely different animal) are single byte, so
0.32 msec long and can be sent _anytime_, even in the middle of any
other type of message.
So, worst case scheduling would seem to me to be around 0.32 msec (ie: I
want the message to be sent at time t+/-320 usec).
This would be for messages that are not sharing the midi stream with
other messages. When you do share the scenario changes. Depending on the
type of message and what is already being sent out the wire we may need
to wait one, two or three midi bytes before we can actually send it, so
we could think of relaxing the requirement to 0.64msec or 0.96 msec. A
stand alone MTC stream (no other midi data sharing the cable) would need
to be scheduled worst case with a precision of one midi bytes (0.32
msec). BUT: I don't know how much jitter external boxes would be able to
tolerate and still sync to the source - and I think that is what would
define what we can get away with in terms of relaxing HZ. I do seem to
remember that HZ=100 made that impossible.
This is taking into account physical Midi bandwidth limitations.
For internal connections through the ALSA sequencer the bandwidth
limitation is gone and we are left with either saying, well, it has to
be at least as good as a cable in terms of scheduling accuracy or we can
drift into perceptual issues such as how much jitter is acceptable in a
rhythmic note-on stream from the point of view of a musician listening
to or playing with it.
We really need high precision timers.........
Or a boot-time choice of HZ value.
-- Fernando
On Wed, 13 Jul 2005 10:49:11 -0400
Eric Dantan Rzewnicki <rzewnickie(a)rfa.org> wrote:
Well, i suppose it's a tradeoff between throughput and responsiveness.
Larger timeslices increase system throughput (less time is spent in the
scheduler) while smaller timeslices increase responsiveness.
Someone proposed HZ=864 which might be OK.
Can someone tell me what the minimum HZ you would need to send MIDI
clock or MTC would be? I think this is a good place to draw the line. Correct,
it's not an issue for apps driven by hardware interrupts like
JACK, because the sound card consumes data at a constant rate. But for
MIDI or video where you have to periodically push data to the device it
matters.
What is driving the kernel-devs to regress on this issue? 
9:03 p.m.
[ Fernando Lopez-Lezcano ]
So, worst case scheduling would seem to me to be
around 0.32 msec (ie: I
want the message to be sent at time t+/-320 usec).
If you want jitter-free MIDI clock, that is absolutely correct. OTOH,
I often wondered why MIDI interfaces are not designed to work in the
same way as an audio card: you write a period of frames, and the HW
takes care of the exact timing of each one. The same could be done
with midi data. It would introduce the same latency we have on audio,
but at least there would not be any jitter.
[ Eric Dantan Rzewnicki ]
I expected something like this. But, I guess my
question was more, who
is complaining about HZ=1024? To which I guess the answer would be
everyone who is more concerned about throughput than latency. Though,
somehow I think that everyone needs a good balance between the two.
I'm not on LKML, but I read the thread from the archives. There seemed
to be two main issues about HZ=1000:
* Some people reported that a kernel build would take 5% more time.
I'd be surprised if this were true. It would mean that the timer
interrupt itself takes 5% of the CPU cycles, and I never noticed that
on my CPU load monitor. And if it is true, it probably means there are
some routines on the timer chain that do not need to be woken up 1000
times per second, and should be on a derived lower frequency task list.
* Apparently, some laptops are draining their batteries at an alarming
rate (in sleep mode) as a result of the 1000 HZ. This could be true, but
indicates a design problem IMHO.
[ Paul Davis ]
no, to make everyone happy we need the High Res Timer
patch. that avoids
the stupidity of a fixed HZ, which is so early '90s that its
embarrassing.
Agreed 100%. I just wonder about the availability of the required
chip on mainstream motherboards. My machine (2 years old now) doesn't
have it, as far as I'm able to find out. Does anyone have more
visibility on this ?
--
FA
9:21 p.m.
On Wed, 2005-07-13 at 16:06, fons adriaensen wrote:
[ Fernando Lopez-Lezcano ]
There were interfaces that did exactly that. The original Roland MPU401
had an "intelligent mode" in which it would schedule things on its own.
There were clones that did that as well (can't remember the brand name).
But this "intelligent mode" was harder to use that the regular raw mode,
so maybe it was not so popular with software developers. That was the
time of blazing fast 4.77MHz (yes "MHz") 8088 cpus when an "infinite
amount of memory" was 640Mbytes :-)
-- Fernando
So, worst case scheduling would seem to me to be
around 0.32 msec (ie: I
want the message to be sent at time t+/-320 usec).
If you want jitter-free MIDI clock, that is absolutely correct. OTOH,
I often wondered why MIDI interfaces are not designed to work in the
same way as an audio card: you write a period of frames, and the HW
takes care of the exact timing of each one. The same could be done
with midi data. It would introduce the same latency we have on audio,
but at least there would not be any jitter.
11:15 p.m.
On Thu, 2005-07-14 at 01:06 +0200, fons adriaensen wrote:
Agreed 100%. I just wonder about the availability of
the required
chip on mainstream motherboards. My machine (2 years old now) doesn't
have it, as far as I'm able to find out. Does anyone have more
visibility on this ?
I guess you're referring to the HPET. The high res timer patch will use
it if available, but it's not required. It works by reprogramming the
PIT, using the TSC or ACPI PM timer for interpolation.
Lee
3:01 p.m.
On Wed, 2005-07-13 at 10:49 -0400, Eric Dantan Rzewnicki wrote:
On Tue, Jul 12, 2005 at 07:34:07PM -0400, Lee Revell
wrote:
Saving battery on laptops. The only performance numbers anyone posted
indicated HZ=250 sped up a kernel compile on a 16 CPU machine (!) by
~5%, and this was after the fact. Not exactly compelling...
But since Linus and Andrew apparently all use laptops, us desktop people
are screwed...
Lee
On Wed, 2005-07-13 at 01:03 +0200, Florian
Schmidt wrote:
What is driving the kernel-devs to regress on this issue?
Some semieducated blabbering ahead (might be all
wrong):
I think i once read that interrupt handling "short circuits" the linux
scheduler (in the sense that not only at every timer interrupt but also
at the end of finishing any interrupt handler the kernel looks which
processes are ready to run etc. and maybe there's a high prio process
waiting just for that interrupt (by i.e. polling or reading on a device
file).
So for all those realtime processes that depend on events that are
triggering interrupts (like soundcards' irqs) the timer interrupt really
doesn't matter. I'm not sure at all though this applies to midi handling
(and especially to alsa_seq when routing from one app to another) or is
even correct in any sense at all :)
Anyone can shed light?
Correct, it's not an issue for apps driven by hardware
interrupts like
JACK, because the sound card consumes data at a constant rate. But for
MIDI or video where you have to periodically push data to the device it
matters.
3:43 p.m.
On Wed, Jul 13, 2005 at 01:01:03PM -0400, Lee Revell wrote:
On Wed, 2005-07-13 at 10:49 -0400, Eric Dantan
Rzewnicki wrote:
Any chance they would make it a config option?
--
Eric Dantan Rzewnicki | Systems Administrator
Technical Operations Division | Radio Free Asia
2025 M Street, NW | Washington, DC 20036 | 202-530-4900
CONFIDENTIAL COMMUNICATION
This e-mail message is intended only for the use of the addressee and
may contain information that is privileged and confidential. Any
unauthorized dissemination, distribution, or copying is strictly
prohibited. If you receive this transmission in error, please contact
network(a)rfa.org.
On Tue, Jul 12, 2005 at 07:34:07PM -0400, Lee
Revell wrote:
Saving
battery on laptops. The only performance numbers anyone posted
indicated HZ=250 sped up a kernel compile on a 16 CPU machine (!) by
~5%, and this was after the fact. Not exactly compelling...
But since Linus and Andrew apparently all use laptops, us desktop people
are screwed... On Wed, 2005-07-13 at 01:03 +0200, Florian
Schmidt wrote:
What is driving the kernel-devs to regress on this issue? Some semieducated blabbering ahead (might be all
wrong):
I think i once read that interrupt handling "short circuits" the linux
scheduler (in the sense that not only at every timer interrupt but also
at the end of finishing any interrupt handler the kernel looks which
processes are ready to run etc. and maybe there's a high prio process
waiting just for that interrupt (by i.e. polling or reading on a device
file).
So for all those realtime processes that depend on events that are
triggering interrupts (like soundcards' irqs) the timer interrupt really
doesn't matter. I'm not sure at all though this applies to midi handling
(and especially to alsa_seq when routing from one app to another) or is
even correct in any sense at all :)
Anyone can shed light?
Correct, it's not an issue for apps driven by hardware
interrupts like
JACK, because the sound card consumes data at a constant rate. But for
MIDI or video where you have to periodically push data to the device it
matters.
3:52 p.m.
On Wed, 2005-07-13 at 13:42 -0400, Eric Dantan Rzewnicki wrote:
Any chance they would make it a config option?
It is a config option, the available settings are 100, 250, and 1000.
The problem is that the default has changed to 250.
Lee
What is driving the kernel-devs to regress on this
issue?
Saving battery on laptops. The only performance numbers anyone posted
indicated HZ=250 sped up a kernel compile on a 16 CPU machine (!) by
~5%, and this was after the fact. Not exactly compelling...
But since Linus and Andrew apparently all use laptops, us desktop people
are screwed...
4:20 p.m.
On Wed, 2005-07-13 at 13:52 -0400, Lee Revell wrote:
On Wed, 2005-07-13 at 13:42 -0400, Eric Dantan
Rzewnicki wrote:
Any chance they would make it a config option?
It is a config option, the available settings are 100, 250, and 1000.
The problem is that the default has changed to 250.
Update: Linus has said that this is a done deal. So now we need to
figure out how to work around it. I guess we'll have to go back to
using the RTC like on 2.4.
Lee
What is driving the kernel-devs to regress on this
issue?
Saving battery on laptops. The only performance numbers anyone posted
indicated HZ=250 sped up a kernel compile on a 16 CPU machine (!) by
~5%, and this was after the fact. Not exactly compelling...
But since Linus and Andrew apparently all use laptops, us desktop people
are screwed...
8:18 p.m.
On Wed, Jul 13, 2005 at 02:20:20PM -0400, Lee Revell wrote:
On Wed, 2005-07-13 at 13:52 -0400, Lee Revell wrote:
I'm confused ... most of us build our own kernels or use kernels built
by Fernando or Free. Why can't kernels just be built with the config
option set to 1000?
--
Eric Dantan Rzewnicki | Systems Administrator
Technical Operations Division | Radio Free Asia
2025 M Street, NW | Washington, DC 20036 | 202-530-4900
CONFIDENTIAL COMMUNICATION
This e-mail message is intended only for the use of the addressee and
may contain information that is privileged and confidential. Any
unauthorized dissemination, distribution, or copying is strictly
prohibited. If you receive this transmission in error, please contact
network(a)rfa.org.
On Wed, 2005-07-13 at 13:42 -0400, Eric Dantan
Rzewnicki wrote:
It is a
config option, the available settings are 100, 250, and 1000.
The problem is that the default has changed to 250.
Update: Linus has said that
this is a done deal. So now we need to
figure out how to work around it. I guess we'll have to go back to
using the RTC like on 2.4. > What
is driving the kernel-devs to regress on this issue?
Saving battery on laptops. The only performance numbers anyone posted
indicated HZ=250 sped up a kernel compile on a 16 CPU machine (!) by
~5%, and this was after the fact. Not exactly compelling...
But since Linus and Andrew apparently all use laptops, us desktop people
are screwed...
Any chance they would make it a config option?
8:26 p.m.
On Wed, 2005-07-13 at 18:17 -0400, Eric Dantan Rzewnicki wrote:
On Wed, Jul 13, 2005 at 02:20:20PM -0400, Lee Revell
wrote:
Because we want MIDI sequencers to work OOTB, like on other OSes.
Lee
On Wed, 2005-07-13 at 13:52 -0400, Lee Revell
wrote:
I'm confused ... most of us build our own kernels or use kernels built
by Fernando or Free. Why can't kernels just be built with the config
option set to 1000?
On Wed, 2005-07-13 at 13:42 -0400, Eric Dantan
Rzewnicki wrote:
Update: Linus has said that
this is a done deal. So now we need to
figure out how to work around it. I guess we'll have to go back to
using the RTC like on 2.4. > > What is driving the kernel-devs to
regress on this issue?
> Saving battery on laptops. The only performance numbers anyone posted
> indicated HZ=250 sped up a kernel compile on a 16 CPU machine (!) by
> ~5%, and this was after the fact. Not exactly compelling...
> But since Linus and Andrew apparently all use laptops, us desktop people
> are screwed...
Any chance they would make it a config option?
It is a config option, the
available settings are 100, 250, and 1000.
The problem is that the default has changed to 250.
8:30 p.m.
On Wed, 2005-07-13 at 15:17, Eric Dantan Rzewnicki wrote:
On Wed, Jul 13, 2005 at 02:20:20PM -0400, Lee Revell
wrote:
They can, what is changing is the default. Which means that out of the
box "normal" distros will not be as suitable to reasonable midi timing
as a tuned kernel. That was not the case in 2.6.x till now.
I don't know about Free but I'd rather not be building kernels forever,
it'd be nice that in a not too distant future regular unadulterated
linux kernels would be good for audio/midi work...
-- Fernando
On Wed, 2005-07-13 at 13:52 -0400, Lee Revell
wrote:
I'm confused ... most of us build our own kernels or use kernels built
by Fernando or Free. Why can't kernels just be built with the config
option set to 1000? On Wed, 2005-07-13 at 13:42 -0400, Eric Dantan
Rzewnicki wrote:
Update: Linus has said that
this is a done deal. So now we need to
figure out how to work around it. I guess we'll have to go back to
using the RTC like on 2.4. > > What is driving the kernel-devs to
regress on this issue?
> Saving battery on laptops. The only performance numbers anyone posted
> indicated HZ=250 sped up a kernel compile on a 16 CPU machine (!) by
> ~5%, and this was after the fact. Not exactly compelling...
> But since Linus and Andrew apparently all use laptops, us desktop people
> are screwed...
Any chance they would make it a config option?
It is a config option, the
available settings are 100, 250, and 1000.
The problem is that the default has changed to 250.
14 Jul
14 Jul
2:30 p.m.
On Wed, Jul 13, 2005 at 03:30:11PM -0700, Fernando Lopez-Lezcano wrote:
On Wed, 2005-07-13 at 15:17, Eric Dantan Rzewnicki
wrote:
Yes. I'm sorry. I was thinking further about my comment all night. I
realized that you and Free are working very hard at providing those
kernels and anything that can make your lives easier will be a good
thing.
Looking forward 6 months to a year from now, I realize it will make my
life much easier as I begin to deploy and maintain at least 30 and
possibly as many as 100+ linux based broadcast workstations.
Again, sorry for saying that. Lost my head there.
Lee, your efforts are very much appreciated, too.
--
Eric Dantan Rzewnicki | Systems Administrator
Technical Operations Division | Radio Free Asia
2025 M Street, NW | Washington, DC 20036 | 202-530-4900
CONFIDENTIAL COMMUNICATION
This e-mail message is intended only for the use of the addressee and
may contain information that is privileged and confidential. Any
unauthorized dissemination, distribution, or copying is strictly
prohibited. If you receive this transmission in error, please contact
network(a)rfa.org.
On Wed, Jul 13, 2005 at 02:20:20PM -0400, Lee
Revell wrote:
They can, what is changing is the default. Which means that
out of the
box "normal" distros will not be as suitable to reasonable midi timing
as a tuned kernel. That was not the case in 2.6.x till now.
I don't know about Free but I'd rather not be building kernels forever,
it'd be nice that in a not too distant future regular unadulterated
linux kernels would be good for audio/midi work... On Wed, 2005-07-13 at 13:52 -0400, Lee Revell
wrote:
I'm confused ... most of us build our own kernels
or use kernels built
by Fernando or Free. Why can't kernels just be built with the config
option set to 1000? On Wed, 2005-07-13 at 13:42 -0400, Eric Dantan
Rzewnicki wrote:
> > > What is driving the kernel-devs to regress on this issue?
> > Saving battery on laptops. The only performance numbers anyone posted
> > indicated HZ=250 sped up a kernel compile on a 16 CPU machine (!) by
> > ~5%, and this was after the fact. Not exactly compelling...
> > But since Linus and Andrew apparently all use laptops, us desktop people
> > are screwed...
> Any chance they would make it a config option?
It is a config option, the available settings are 100, 250, and 1000.
The problem is that the default has changed to 250.
Update: Linus has said that
this is a done deal. So now we need to
figure out how to work around it. I guess we'll have to go back to
using the RTC like on 2.4.
7075
days inactive
7077
days old
linux-audio-user@lists.linuxaudio.org
19 comments
6 participants
participants (6)
-
Eric Dantan Rzewnicki -
Fernando Lopez-Lezcano -
Florian Schmidt -
fons adriaensen -
Kjetil Svalastog Matheussen <k.s.matheussen＠notam02.no> -
Lee Revell