On Thu, 2005-07-14 at 09:57 +1000, Con Kolivas wrote:
> On Thu, 14 Jul 2005 03:34, Lee Revell wrote:
> > On Wed, 2005-07-13 at 13:27 +0200, szonyi calin wrote:
> > > I have the following problem with audio:
> > > Xmms is running with threads for audio and spe
On Fri, 2005-07-15 at 14:01 +1000, Con Kolivas wrote:
> Interbech is a an application is designed to benchmark interactivity in Linux.
>
> Version 0.21 update
>
> http://ck.kolivas.org/apps/interbench/interbench-0.21.tar.bz2
>
I would suggest using microseconds for both the RT and non RT
On Fri, 2005-07-15 at 14:01 +1000, Con Kolivas wrote:
> his makes a large difference to the latencies measured under mem_load
> particularly when running real time benchmarks on a RT-PREEMPT kernel
Here are some results from my 600MHz C3. In realtime mode, the
PREEMPT_RT kernel performs as
On Fri, 2005-07-15 at 14:01 +1000, Con Kolivas wrote:
his makes a large difference to the latencies measured under mem_load
particularly when running real time benchmarks on a RT-PREEMPT kernel
Here are some results from my 600MHz C3. In realtime mode, the
PREEMPT_RT kernel performs as
On Fri, 2005-07-15 at 14:01 +1000, Con Kolivas wrote:
Interbech is a an application is designed to benchmark interactivity in Linux.
Version 0.21 update
http://ck.kolivas.org/apps/interbench/interbench-0.21.tar.bz2
I would suggest using microseconds for both the RT and non RT tests. It
On Thu, 2005-07-14 at 09:57 +1000, Con Kolivas wrote:
On Thu, 14 Jul 2005 03:34, Lee Revell wrote:
On Wed, 2005-07-13 at 13:27 +0200, szonyi calin wrote:
I have the following problem with audio:
Xmms is running with threads for audio and spectrum
analyzer(OpenGL).
The audio eats 5
On Sun, 2005-07-17 at 04:13 +0200, Jesper Juhl wrote:
Where do we actually program the tick rate we want?
In arch/i386/kernel/timers/timer_pit.c:
166 void setup_pit_timer(void)
167 {
168 unsigned long flags;
169
170 spin_lock_irqsave(i8253_lock, flags);
On Sun, 2005-07-17 at 04:38 +0200, Adrian Bunk wrote:
SCSI_QLA2XXX is automatically enabled for (SCSI PCI).
This has bugged me for a while. Why does this one SCSI driver default
to Y in the first place?
Lee
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Sat, 2005-07-16 at 19:35 -0700, Nish Aravamudan wrote:
As you've seen, I think it depends on the timesource: for the PIT, it
would be arch/i386/kernel/timers/timer_pit.c::setup_pit_timer().
That one looks pretty straightforward.
arch/i386/kernel/timers/timer_tsc.c really looks like fun. So
On Sat, 2005-07-16 at 21:04 -0700, randy_dunlap wrote:
On Sat, 16 Jul 2005 23:11:26 -0400 Lee Revell wrote:
On Sun, 2005-07-17 at 04:38 +0200, Adrian Bunk wrote:
SCSI_QLA2XXX is automatically enabled for (SCSI PCI).
This has bugged me for a while. Why does this one SCSI driver
On Fri, 2005-07-15 at 14:24 -0500, Lee wrote:
> Hi,
>
> > > [20975.978911] PREEMPT SMP DEBUG_PAGEALLOC
> > > [20976.029194] Modules linked in: vmnet vmmon nvidia
> > > [20976.090907] CPU:695757158
> > > [20976.090909] EIP:0060:[]Tainted: P VLI
> >
> > Please reproduce the bug
On Fri, 2005-07-15 at 14:04 -0500, Lee wrote:
> [20975.978911] PREEMPT SMP DEBUG_PAGEALLOC
> [20976.029194] Modules linked in: vmnet vmmon nvidia
> [20976.090907] CPU:695757158
> [20976.090909] EIP:0060:[]Tainted: P VLI
Please reproduce the bug without these proprietary modules
On Thu, 2005-07-14 at 22:54 -0600, Zwane Mwaikambo wrote:
> On Fri, 15 Jul 2005, Lee Revell wrote:
>
> > On Fri, 2005-07-15 at 14:08 +1000, Con Kolivas wrote:
> > > Audio did show slightly larger max latencies but nothing that would be of
> > > significance.
On Fri, 2005-07-15 at 08:57 -0700, Christoph Lameter wrote:
> Try HPET which is pretty standard these days.
>
Really? None of my machines have it. I suspect lots of "embeddable"
systems don't either.
Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Fri, 2005-07-15 at 08:57 -0700, Christoph Lameter wrote:
Try HPET which is pretty standard these days.
Really? None of my machines have it. I suspect lots of embeddable
systems don't either.
Lee
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
On Thu, 2005-07-14 at 22:54 -0600, Zwane Mwaikambo wrote:
On Fri, 15 Jul 2005, Lee Revell wrote:
On Fri, 2005-07-15 at 14:08 +1000, Con Kolivas wrote:
Audio did show slightly larger max latencies but nothing that would be of
significance.
On video, maximum latencies are only
On Fri, 2005-07-15 at 14:04 -0500, Lee wrote:
[20975.978911] PREEMPT SMP DEBUG_PAGEALLOC
[20976.029194] Modules linked in: vmnet vmmon nvidia
[20976.090907] CPU:695757158
[20976.090909] EIP:0060:[c0119ed8]Tainted: P VLI
Please reproduce the bug without these proprietary
On Fri, 2005-07-15 at 14:24 -0500, Lee wrote:
Hi,
[20975.978911] PREEMPT SMP DEBUG_PAGEALLOC
[20976.029194] Modules linked in: vmnet vmmon nvidia
[20976.090907] CPU:695757158
[20976.090909] EIP:0060:[c0119ed8]Tainted: P VLI
Please reproduce the bug without these
On Fri, 2005-07-15 at 14:08 +1000, Con Kolivas wrote:
> Audio did show slightly larger max latencies but nothing that would be of
> significance.
>
> On video, maximum latencies are only slightly larger at HZ 250, all the
> desired cpu was achieved, but the average latency and number of missed
On Fri, 2005-07-15 at 03:55 +0300, Zvi Rackover wrote:
> hello all,
>
> i wish to write a module for i386 that can hook interrupts. the module
> loads its own interrupt descriptor table instead of the default
> system's table. after executing my own handler(s), the old appropriate
> handler will
On Fri, 2005-07-15 at 02:04 +0200, Jesper Juhl wrote:
> While reading this thread it occoured to me that perhaps what we
> really want (besides sub HZ timers) might be for the kernel to
> auto-tune HZ?
>
> Would it make sense to introduce a new config option (say
> CONFIG_HZ_AUTO) that when
On Thu, 2005-07-14 at 16:49 -0700, Linus Torvalds wrote:
>
> On Thu, 14 Jul 2005, Lee Revell wrote:
> >
> > And I'm incredibly frustrated by this insistence on hard data when it's
> > completely obvious to anyone who knows the first thing about MIDI that
> > HZ=250
On Thu, 2005-07-14 at 16:49 -0700, Linus Torvalds wrote:
> YOUR argument is "nobody else matters, only I do".
>
> MY argument is that this is a case of give and take.
I wouldn't say that. I do agree with you that HZ=1000 for everyone is
problematic, I just feel that a reasonable compromise is
On Thu, 2005-07-14 at 16:25 -0700, Linus Torvalds wrote:
> On Thu, 14 Jul 2005, Lee Revell wrote:
> > This thread has really gone OT, but to revisit the original issue for a
> > bit, are you still unwilling to consider leaving the default HZ at 1000
> > for 2.6.13?
>
On Thu, 2005-07-14 at 16:25 -0700, Linus Torvalds wrote:
> Yes. I see absolutely no point to it until I actually hear people who have
> actually tried some real load that doesn't work. Dammit, I want a real
> user who says that he can noticeable see his DVD stuttering, not some
> theory.
>
>
On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
> I have to say, this whole thread has been pretty damn worthless in
> general in my not-so-humble opinion.
>
This thread has really gone OT, but to revisit the original issue for a
bit, are you still unwilling to consider leaving the
On Thu, 2005-07-14 at 20:58 +0100, Alistair John Strachan wrote:
> the responsiveness of our instrument to 300us which is low enough
> for the real-time PCR industry
PCR, as in polymerase chain reaction? They can do that in realtime?
Impressive.
Lee
-
To unsubscribe from this list: send the
On Thu, 2005-07-14 at 08:02 -0700, Christoph Lameter wrote:
> I doubt that increasing the timer frequency is the way to go to solve
> these issues. HZ should be as low as possible and we should strive for
> a tickless system.
Agreed. Most of those applications are driven by their own interrupt
On Thu, 2005-07-14 at 10:38 +0200, Ingo Molnar wrote:
> - there are real-time applications (robotic environments: fast rotating
>tools, media and mobile/phone applications, etc.) that want 10
>usecs precision. If such users increased HZ to 100,000 or even
>1000,000, the current timer
On Thu, 2005-07-14 at 11:24 +0200, Jan Engelhardt wrote:
> "My expectation is if we want to beat the competition, we'll want
> the ability to go *under* 100Hz."
> >>>
> >>> What does Windows do here?
> >>
> >> windows xp base rate is 100Hz... but multimedia apps can ask for almost
> >
On Thu, 2005-07-14 at 11:24 +0200, Jan Engelhardt wrote:
My expectation is if we want to beat the competition, we'll want
the ability to go *under* 100Hz.
What does Windows do here?
windows xp base rate is 100Hz... but multimedia apps can ask for almost
83Hz
Well, Windoes 98
On Thu, 2005-07-14 at 08:02 -0700, Christoph Lameter wrote:
I doubt that increasing the timer frequency is the way to go to solve
these issues. HZ should be as low as possible and we should strive for
a tickless system.
Agreed. Most of those applications are driven by their own interrupt
On Thu, 2005-07-14 at 20:58 +0100, Alistair John Strachan wrote:
the responsiveness of our instrument to 300us which is low enough
for the real-time PCR industry
PCR, as in polymerase chain reaction? They can do that in realtime?
Impressive.
Lee
-
To unsubscribe from this list: send the
On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
I have to say, this whole thread has been pretty damn worthless in
general in my not-so-humble opinion.
This thread has really gone OT, but to revisit the original issue for a
bit, are you still unwilling to consider leaving the default
On Thu, 2005-07-14 at 16:25 -0700, Linus Torvalds wrote:
Yes. I see absolutely no point to it until I actually hear people who have
actually tried some real load that doesn't work. Dammit, I want a real
user who says that he can noticeable see his DVD stuttering, not some
theory.
I'm
On Thu, 2005-07-14 at 16:25 -0700, Linus Torvalds wrote:
On Thu, 14 Jul 2005, Lee Revell wrote:
This thread has really gone OT, but to revisit the original issue for a
bit, are you still unwilling to consider leaving the default HZ at 1000
for 2.6.13?
Yes. I see absolutely no point
On Thu, 2005-07-14 at 16:49 -0700, Linus Torvalds wrote:
YOUR argument is nobody else matters, only I do.
MY argument is that this is a case of give and take.
I wouldn't say that. I do agree with you that HZ=1000 for everyone is
problematic, I just feel that a reasonable compromise is
On Thu, 2005-07-14 at 16:49 -0700, Linus Torvalds wrote:
On Thu, 14 Jul 2005, Lee Revell wrote:
And I'm incredibly frustrated by this insistence on hard data when it's
completely obvious to anyone who knows the first thing about MIDI that
HZ=250 will fail in situations where HZ=1000
On Fri, 2005-07-15 at 02:04 +0200, Jesper Juhl wrote:
While reading this thread it occoured to me that perhaps what we
really want (besides sub HZ timers) might be for the kernel to
auto-tune HZ?
Would it make sense to introduce a new config option (say
CONFIG_HZ_AUTO) that when selected
On Fri, 2005-07-15 at 03:55 +0300, Zvi Rackover wrote:
hello all,
i wish to write a module for i386 that can hook interrupts. the module
loads its own interrupt descriptor table instead of the default
system's table. after executing my own handler(s), the old appropriate
handler will be
On Fri, 2005-07-15 at 14:08 +1000, Con Kolivas wrote:
Audio did show slightly larger max latencies but nothing that would be of
significance.
On video, maximum latencies are only slightly larger at HZ 250, all the
desired cpu was achieved, but the average latency and number of missed
On Wed, 2005-07-13 at 18:13 -0700, dean gaudet wrote:
> http://www.microsoft.com/whdc/system/CEC/mm-timer.mspx
Did anyone else find this strange:
"The RTC is used in periodic mode to provide the system profiling
interrupt on uni-processor systems and the clock interrupt on
multi-processor
On Wed, 2005-07-13 at 18:13 -0700, dean gaudet wrote:
> On Wed, 13 Jul 2005, Chris Wedgwood wrote:
>
> > On Wed, Jul 13, 2005 at 04:41:41PM -0700, dean gaudet wrote:
> >
> > > windows xp base rate is 100Hz... but multimedia apps can ask for
> > > almost any rate they want (depends on the hw
On Tue, 2005-07-12 at 23:58 -0700, Paul Jackson wrote:
> Dick Johnson wrote:
> > Or just disallow tabs altogether. At Analogic we ...
>
> This is the Linux kernel, not Analogic.
>
> We use tabs for indentation. You can set the number
> of physical spaces per tab however you want in your
>
On Tue, 2005-07-12 at 22:05 -0700, Linus Torvalds wrote:
> I think the shortlog speaks for itself.
HZ still defaults to 250. As was explained in another thread, this will
break apps like MIDI sequencers and won't really save much battery
power.
The default should remain 1000 until these issues
On Wed, 2005-07-13 at 14:16 -0700, Chris Wedgwood wrote:
>(1) ACPI/SMM suckage in laptops
Anything that loses ticks at 1000HZ is unsuitable for serious multimedia
use anyway, so I think this part of the argument isn't as important.
Also, I don't know that anyone has a list of machines with
On Wed, 2005-07-13 at 14:16 -0700, Chris Wedgwood wrote:
> Both can be detected from you .config and we could see HZ as needed
> there and everyone else could avoid this surely?
Does anyone object to setting HZ at boot? I suspect nothing else will
make everyone happy.
Lee
-
To unsubscribe from
On Wed, 2005-07-13 at 14:32 -0500, Dmitry Torokhov wrote:
> Hi,
>
> On 7/13/05, Lee Revell <[EMAIL PROTECTED]> wrote:
> > On Wed, 2005-07-13 at 12:10 -0700, Linus Torvalds wrote:
> > > So we should aim for a HZ value that makes it easy to convert to and from
On Wed, 2005-07-13 at 12:33 -0700, Martin J. Bligh wrote:
>
> --On Wednesday, July 13, 2005 14:32:02 -0500 Dmitry Torokhov <[EMAIL
> PROTECTED]> wrote:
>
> > Hi,
> >
> > On 7/13/05, Lee Revell <[EMAIL PROTECTED]> wrote:
> >> On Wed, 2005-07-13
On Wed, 2005-07-13 at 15:11 -0400, Bill Davidsen wrote:
> Paul Slootman wrote:
> > Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> >
> >>What's the gain in parking the head manually if it's done anyway when the
> >>disk
> >>spins down (for whatever reason)?
> >
> >
> > It seems you're completely
On Wed, 2005-07-13 at 12:10 -0700, Linus Torvalds wrote:
> So we should aim for a HZ value that makes it easy to convert to and from
> the standard user-space interface formats. 100Hz, 250Hz and 1000Hz are all
> good values for that reason. 864 is not.
How about 500? This might be good enough to
On Wed, 2005-07-13 at 10:51 -0700, Linus Torvalds wrote:
>
> On Wed, 13 Jul 2005, Lee Revell wrote:
>
> > On Tue, 2005-07-12 at 22:05 -0700, Linus Torvalds wrote:
> > > I think the shortlog speaks for itself.
> >
> > HZ still defaults to 250.
On Wed, 2005-07-13 at 13:27 +0200, szonyi calin wrote:
> I have the following problem with audio:
> Xmms is running with threads for audio and spectrum
> analyzer(OpenGL).
> The audio eats 5% cpu, the spectrum analyzer about 80 %. The
> problem is that sometimes the spectrum analyzer is eating all
On Wed, 2005-07-13 at 08:35 +0200, Ingo Molnar wrote:
> * Lee Revell <[EMAIL PROTECTED]> wrote:
>
> > > I have found that heavy network traffic really kills the interactive
> > > performance. In the top excerpt below, gtk-gnutella is generating ab
On Wed, 2005-07-13 at 11:59 -0400, Bill Davidsen wrote:
> Theodore Ts'o wrote:
> > The real answer here is for the tickless patches to cleaned up to the
> > point where they can be merged, and then we won't waste battery power
> > entering the timer interrupt in the first place. :-)
>
> And that
On Wed, 2005-07-13 at 12:26 -0400, Bill Davidsen wrote:
> >
> > Going to HZ=864 would fix this problem. It would likely cause other
> > problems in places that expect 1/HZ to be a sane number, though.
> >
> But if you are going to an "odd" value, would 1381 would be a better
> choice, given
On Wed, 2005-07-13 at 12:26 -0400, Bill Davidsen wrote:
Going to HZ=864 would fix this problem. It would likely cause other
problems in places that expect 1/HZ to be a sane number, though.
But if you are going to an odd value, would 1381 would be a better
choice, given the interest
On Wed, 2005-07-13 at 11:59 -0400, Bill Davidsen wrote:
Theodore Ts'o wrote:
The real answer here is for the tickless patches to cleaned up to the
point where they can be merged, and then we won't waste battery power
entering the timer interrupt in the first place. :-)
And that does
On Wed, 2005-07-13 at 08:35 +0200, Ingo Molnar wrote:
* Lee Revell [EMAIL PROTECTED] wrote:
I have found that heavy network traffic really kills the interactive
performance. In the top excerpt below, gtk-gnutella is generating about
320KB/sec of traffic.
These priorities do
On Wed, 2005-07-13 at 13:27 +0200, szonyi calin wrote:
I have the following problem with audio:
Xmms is running with threads for audio and spectrum
analyzer(OpenGL).
The audio eats 5% cpu, the spectrum analyzer about 80 %. The
problem is that sometimes the spectrum analyzer is eating all of
On Wed, 2005-07-13 at 10:51 -0700, Linus Torvalds wrote:
On Wed, 13 Jul 2005, Lee Revell wrote:
On Tue, 2005-07-12 at 22:05 -0700, Linus Torvalds wrote:
I think the shortlog speaks for itself.
HZ still defaults to 250. As was explained in another thread, this will
break apps like
On Wed, 2005-07-13 at 12:10 -0700, Linus Torvalds wrote:
So we should aim for a HZ value that makes it easy to convert to and from
the standard user-space interface formats. 100Hz, 250Hz and 1000Hz are all
good values for that reason. 864 is not.
How about 500? This might be good enough to
On Wed, 2005-07-13 at 15:11 -0400, Bill Davidsen wrote:
Paul Slootman wrote:
Jan Engelhardt [EMAIL PROTECTED] wrote:
What's the gain in parking the head manually if it's done anyway when the
disk
spins down (for whatever reason)?
It seems you're completely missing the whole
On Wed, 2005-07-13 at 12:33 -0700, Martin J. Bligh wrote:
--On Wednesday, July 13, 2005 14:32:02 -0500 Dmitry Torokhov [EMAIL
PROTECTED] wrote:
Hi,
On 7/13/05, Lee Revell [EMAIL PROTECTED] wrote:
On Wed, 2005-07-13 at 12:10 -0700, Linus Torvalds wrote:
So we should aim for a HZ
On Wed, 2005-07-13 at 14:32 -0500, Dmitry Torokhov wrote:
Hi,
On 7/13/05, Lee Revell [EMAIL PROTECTED] wrote:
On Wed, 2005-07-13 at 12:10 -0700, Linus Torvalds wrote:
So we should aim for a HZ value that makes it easy to convert to and from
the standard user-space interface formats
On Wed, 2005-07-13 at 14:16 -0700, Chris Wedgwood wrote:
Both can be detected from you .config and we could see HZ as needed
there and everyone else could avoid this surely?
Does anyone object to setting HZ at boot? I suspect nothing else will
make everyone happy.
Lee
-
To unsubscribe from
On Wed, 2005-07-13 at 14:16 -0700, Chris Wedgwood wrote:
(1) ACPI/SMM suckage in laptops
Anything that loses ticks at 1000HZ is unsuitable for serious multimedia
use anyway, so I think this part of the argument isn't as important.
Also, I don't know that anyone has a list of machines with
On Tue, 2005-07-12 at 22:05 -0700, Linus Torvalds wrote:
I think the shortlog speaks for itself.
HZ still defaults to 250. As was explained in another thread, this will
break apps like MIDI sequencers and won't really save much battery
power.
The default should remain 1000 until these issues
On Tue, 2005-07-12 at 23:58 -0700, Paul Jackson wrote:
Dick Johnson wrote:
Or just disallow tabs altogether. At Analogic we ...
This is the Linux kernel, not Analogic.
We use tabs for indentation. You can set the number
of physical spaces per tab however you want in your
editor, but it
On Wed, 2005-07-13 at 18:13 -0700, dean gaudet wrote:
On Wed, 13 Jul 2005, Chris Wedgwood wrote:
On Wed, Jul 13, 2005 at 04:41:41PM -0700, dean gaudet wrote:
windows xp base rate is 100Hz... but multimedia apps can ask for
almost any rate they want (depends on the hw capabilities).
On Wed, 2005-07-13 at 18:13 -0700, dean gaudet wrote:
http://www.microsoft.com/whdc/system/CEC/mm-timer.mspx
Did anyone else find this strange:
The RTC is used in periodic mode to provide the system profiling
interrupt on uni-processor systems and the clock interrupt on
multi-processor systems.
On Tue, 2005-07-12 at 15:22 -0700, Martin J. Bligh wrote:
>
> --On Tuesday, July 12, 2005 16:58:44 -0400 Lee Revell <[EMAIL PROTECTED]>
> wrote:
>
> > On Mon, 2005-07-11 at 21:30 -0700, Martin J. Bligh wrote:
> >> Some sort of comprimise has to be struck for now
On Tue, 2005-07-12 at 21:18 -0400, Lee Revell wrote:
> On Mon, 2005-07-04 at 13:16 +0200, Ingo Molnar wrote:
> > i'd first suggest to try the latest kernel, before changing your X
> > config - i think the bug might have been fixed meanwhile.
>
> I have found that heavy n
On Mon, 2005-07-04 at 13:16 +0200, Ingo Molnar wrote:
> i'd first suggest to try the latest kernel, before changing your X
> config - i think the bug might have been fixed meanwhile.
I have found that heavy network traffic really kills the interactive
performance. In the top excerpt below,
On Tue, 2005-07-12 at 19:37 -0400, Keenan Pepper wrote:
> but I'm not sure if that's right. I guess I'll see when I try to boot it!
>
The standard fix is to make it a compat_semaphore. See the list
archives for details.
Lee
-
To unsubscribe from this list: send the line "unsubscribe
0 seems like a reasonable comprimise to me. Exactly what problems
> *does* it cause (in visible effect, not "timers are less granular").
> Jittery audio/video? How much worse is it?
OK, here's a real world example, taken straight from the linux-audio-dev
list today.
Lee
On Mon, 2005-07-11 at 17:07 +0200, Ingo Molnar wrote:
> I've uploaded -27 with the fix - but it should
> only confirm that it's not a stack overflow.
V0.7.51-28 does not compile:
CC [M] sound/oss/emu10k1/midi.o
sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__'
On Tue, 2005-07-12 at 15:55 -0400, Keenan Pepper wrote:
> Ingo Molnar's realtime-preempt patches used to be based on the -mm
> kernels, but now they appear to be based on the mainline kernels, so
> they don't support reiser4 (at least until reiser4 is merged into
> mainline, which is looking
On Tue, 2005-07-12 at 08:08 -0700, Martin J. Bligh wrote:
> Well, looking forward, you'll have sub-HZ timers, so none of this will
> matter. Actually, looking at the above, 150 seems perfectly reasonable
> to me, but 300 seems to be close enough. I'll run some numbers on
> both.
>
> From your
On Tue, 2005-07-12 at 10:55 -0700, David Lang wrote:
> On Tue, 12 Jul 2005, Lee Revell wrote:
>
> > On Tue, 2005-07-12 at 05:17 -0700, David Lang wrote:
> >> for example a series 1 DirectTv tivo manages to write two program
> >> streams to disk while reading and vi
On Tue, 2005-07-12 at 05:17 -0700, David Lang wrote:
> for example a series 1 DirectTv tivo manages to write two program
> streams to disk while reading and viewing a third
Actually it writes two streams to disk while reading and viewing one of
them, unless they released a model with three
On Tue, 2005-07-12 at 08:08 -0700, Martin J. Bligh wrote:
> Well, looking forward, you'll have sub-HZ timers, so none of this will
> matter. Actually, looking at the above, 150 seems perfectly reasonable
> to me, but 300 seems to be close enough. I'll run some numbers on both.
>
> >From your
On Tue, 2005-07-12 at 21:52 +1000, Con Kolivas wrote:
> > Well, it's just the default settings of the kernel which has changed. If
> > you want the old behaviour, you can use (with your admin hat):
> > echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice
> > IMHO it seems quite fair,
On Tue, 2005-07-12 at 07:56 -0700, Martin J. Bligh wrote:
> --Lee Revell <[EMAIL PROTECTED]> wrote (on Tuesday, July 12, 2005 10:24:59
> -0400):
>
> > On Mon, 2005-07-11 at 21:30 -0700, Martin J. Bligh wrote:
> >> Exactly what problems
> >> *does* i
On Mon, 2005-07-11 at 21:30 -0700, Martin J. Bligh wrote:
> Exactly what problems
> *does* it cause (in visible effect, not "timers are less granular").
> Jittery audio/video? How much worse is it?
Yes, exactly. Say you need to deliver a frame of audio or video every
5ms. You have a rendering
On Mon, 2005-07-11 at 21:30 -0700, Martin J. Bligh wrote:
> Look back in the thread. It made kernel compiles about 5% faster on a
> fairly large box. I think the SGI people did it originally because it
> caused them even larger problems.
>
Right, I saw those, but you don't expect to change the
a reasonable comprimise to me. Exactly what problems
*does* it cause (in visible effect, not timers are less granular).
Jittery audio/video? How much worse is it?
OK, here's a real world example, taken straight from the linux-audio-dev
list today.
Lee
Lee Revell [EMAIL PROTECTED] :
On Tue, 2005-07
On Tue, 2005-07-12 at 19:37 -0400, Keenan Pepper wrote:
but I'm not sure if that's right. I guess I'll see when I try to boot it!
The standard fix is to make it a compat_semaphore. See the list
archives for details.
Lee
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Mon, 2005-07-04 at 13:16 +0200, Ingo Molnar wrote:
i'd first suggest to try the latest kernel, before changing your X
config - i think the bug might have been fixed meanwhile.
I have found that heavy network traffic really kills the interactive
performance. In the top excerpt below,
On Tue, 2005-07-12 at 21:18 -0400, Lee Revell wrote:
On Mon, 2005-07-04 at 13:16 +0200, Ingo Molnar wrote:
i'd first suggest to try the latest kernel, before changing your X
config - i think the bug might have been fixed meanwhile.
I have found that heavy network traffic really kills
On Tue, 2005-07-12 at 15:22 -0700, Martin J. Bligh wrote:
--On Tuesday, July 12, 2005 16:58:44 -0400 Lee Revell [EMAIL PROTECTED]
wrote:
On Mon, 2005-07-11 at 21:30 -0700, Martin J. Bligh wrote:
Some sort of comprimise has to be struck for now, until we get sub-HZ
timers. I'd prefer
On Mon, 2005-07-11 at 21:30 -0700, Martin J. Bligh wrote:
Look back in the thread. It made kernel compiles about 5% faster on a
fairly large box. I think the SGI people did it originally because it
caused them even larger problems.
Right, I saw those, but you don't expect to change the
On Mon, 2005-07-11 at 21:30 -0700, Martin J. Bligh wrote:
Exactly what problems
*does* it cause (in visible effect, not timers are less granular).
Jittery audio/video? How much worse is it?
Yes, exactly. Say you need to deliver a frame of audio or video every
5ms. You have a rendering thread
On Tue, 2005-07-12 at 07:56 -0700, Martin J. Bligh wrote:
--Lee Revell [EMAIL PROTECTED] wrote (on Tuesday, July 12, 2005 10:24:59
-0400):
On Mon, 2005-07-11 at 21:30 -0700, Martin J. Bligh wrote:
Exactly what problems
*does* it cause (in visible effect, not timers are less granular
On Tue, 2005-07-12 at 21:52 +1000, Con Kolivas wrote:
Well, it's just the default settings of the kernel which has changed. If
you want the old behaviour, you can use (with your admin hat):
echo 1 /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice
IMHO it seems quite fair, if you
On Tue, 2005-07-12 at 08:08 -0700, Martin J. Bligh wrote:
Well, looking forward, you'll have sub-HZ timers, so none of this will
matter. Actually, looking at the above, 150 seems perfectly reasonable
to me, but 300 seems to be close enough. I'll run some numbers on both.
From your above
On Tue, 2005-07-12 at 05:17 -0700, David Lang wrote:
for example a series 1 DirectTv tivo manages to write two program
streams to disk while reading and viewing a third
Actually it writes two streams to disk while reading and viewing one of
them, unless they released a model with three
On Tue, 2005-07-12 at 10:55 -0700, David Lang wrote:
On Tue, 12 Jul 2005, Lee Revell wrote:
On Tue, 2005-07-12 at 05:17 -0700, David Lang wrote:
for example a series 1 DirectTv tivo manages to write two program
streams to disk while reading and viewing a third
Actually it writes two
On Tue, 2005-07-12 at 08:08 -0700, Martin J. Bligh wrote:
Well, looking forward, you'll have sub-HZ timers, so none of this will
matter. Actually, looking at the above, 150 seems perfectly reasonable
to me, but 300 seems to be close enough. I'll run some numbers on
both.
From your above
On Tue, 2005-07-12 at 15:55 -0400, Keenan Pepper wrote:
Ingo Molnar's realtime-preempt patches used to be based on the -mm
kernels, but now they appear to be based on the mainline kernels, so
they don't support reiser4 (at least until reiser4 is merged into
mainline, which is looking
601 - 700 of 1258 matches
Mail list logo
