Lee Revell:
On Fri, 2005-07-15 at 23:10 +0200, Kjetil Svalastog Matheussen wrote:
I wonder why /dev/rtc isn't used more than it is now.
Because sleep/wakeup, poll, etc are much nicer interfaces than /dev/rtc.
If you had read the part of my mail that you cut away
when quoting me, you would
On Sat, 2005-07-16 at 08:33 +0200, Kjetil Svalastog Matheussen wrote:
This is easely solved by setting up a server-system. The clients
can request an individually frequency to be woken up by, and
the server will set the interrupt freq high enough to satisfy
all current connected clients.
Plus not all machines have a physical RTC chip.
If you want periodic interrupt emulation on those you need a patch [1],
but that just generates a software interrupt. That would suffer from a
change in HZ value AFAIK.
--
Martin
[1]
On Thu, 14 Jul 2005, fons adriaensen wrote:
[ 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
On Fri, 2005-07-15 at 23:10 +0200, Kjetil Svalastog Matheussen wrote:
I wonder why /dev/rtc isn't used more than it is now.
Because sleep/wakeup, poll, etc are much nicer interfaces than /dev/rtc.
Lee
On Fri, 2005-07-15 at 17:18 -0400, Lee Revell wrote:
On Fri, 2005-07-15 at 23:10 +0200, Kjetil Svalastog Matheussen wrote:
I wonder why /dev/rtc isn't used more than it is now.
Because sleep/wakeup, poll, etc are much nicer interfaces than /dev/rtc.
any sane programmer will use slee/wakeup,
On Fri, 2005-07-15 at 17:37 -0400, Paul Davis wrote:
On Fri, 2005-07-15 at 17:18 -0400, Lee Revell wrote:
On Fri, 2005-07-15 at 23:10 +0200, Kjetil Svalastog Matheussen wrote:
I wonder why /dev/rtc isn't used more than it is now.
Because sleep/wakeup, poll, etc are much nicer interfaces
On Thu, 14 Jul 2005 11:38:37 +0300, Sampo Savolainen wrote:
Quoting Eric Dantan Rzewnicki [EMAIL PROTECTED]:
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?
Free? It's my turn
On Wed, 2005-07-13 at 18:20 -0400, Paul Davis wrote:
I suppose to make everyone happy this should be runtime configurable.
Incorporating which would be quite a task :)
no, to make everyone happy we need the High Res Timer patch. that avoids
the stupidity of a fixed HZ, which is so early
On Thu, Jul 14, 2005 at 11:38:37AM +0300, Sampo Savolainen wrote:
Quoting Eric Dantan Rzewnicki [EMAIL PROTECTED]:
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?
Free? It's my
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:
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:
On Wed, 2005-07-13 at 13:42 -0400, Eric
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:
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
On Wed, 13 Jul 2005 10:49:11 -0400
Eric Dantan Rzewnicki [EMAIL PROTECTED] wrote:
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
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 [EMAIL PROTECTED] wrote:
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
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:
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
On Wed, 2005-07-13 at 18:31 +0200, Florian Schmidt wrote:
On Wed, 13 Jul 2005 10:49:11 -0400
Eric Dantan Rzewnicki [EMAIL PROTECTED] wrote:
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
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:
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:
Some semieducated blabbering ahead (might be
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
On Wed, 2005-07-13 at 10:27, Lee Revell wrote:
On Wed, 2005-07-13 at 18:31 +0200, Florian Schmidt wrote:
On Wed, 13 Jul 2005 10:49:11 -0400
Eric Dantan Rzewnicki [EMAIL PROTECTED] wrote:
Correct, it's not an issue for apps driven by hardware interrupts like
JACK, because the sound
On Wed, 13 Jul 2005 12:44:32 -0400
Eric Dantan Rzewnicki [EMAIL PROTECTED] 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,
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:
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
I suppose to make everyone happy this should be runtime configurable.
Incorporating which would be quite a task :)
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.
--p
On Wed, 2005-07-13 at 18:20 -0400, Paul Davis wrote:
I suppose to make everyone happy this should be runtime configurable.
Incorporating which would be quite a task :)
no, to make everyone happy we need the High Res Timer patch. that avoids
the stupidity of a fixed HZ, which is so early
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:
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:
What is driving the kernel-devs to regress on this
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:
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:
What is driving the kernel-devs to regress on
[ 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
On Wed, 2005-07-13 at 16:06, fons adriaensen wrote:
[ 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
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
Download from http://www.notam02.no/arkiv/src/
E-Radium V0.61b
---
Released 12.7.2005
INTRODUCTION
E-radium is Radium and a special version of E-UAE.
Radium is a midi music editor for the amiga and E-Uae is an amiga
emulator.
This version of E-Uae is a hacked
On Tue, 2005-07-12 at 20:57 +0200, Kjetil Svalastog Matheussen wrote:
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
Lee Revell [EMAIL PROTECTED]
On Tue, 2005-07-12 at 20:57 +0200, Kjetil Svalastog Matheussen wrote:
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
On Tue, 12 Jul 2005 22:35:24 +0200 (CEST)
Kjetil Svalastog Matheussen [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
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
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
33 matches
Mail list logo
