Martin Habets:
>
> 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.
>
When having a server, you don't have to use /dev/rtc
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] http://www.mph.eclipse.co.uk/pub/linux/patches/2.6.8/genrtc.c.pat
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.
>
Paul Davis:
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 us
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 h
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 i
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/wak
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 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 mainstrea
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, E
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?
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 ea
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
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
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 oft
[ 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
sa
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
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 regre
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 ea
> 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, 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 per
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, 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, be
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 numbers anyone posted
> > > indicated HZ=250 sped up a kern
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 a
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 (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 <[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
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 handlin
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.
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 t
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 a
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 in
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
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
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
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 vers
36 matches
Mail list logo
