On Thu, 8 Jul 1999 09:54:42 +0100 (BST),
Doug Rabson [EMAIL PROTECTED] said:
dfr If I understand this correctly, you are suggesting that we program timer0
dfr so that we only take interrupts when a finetimer is due to fire? If so,
dfr then it sounds very good. The idea of taking 6000+
On Wed, 14 Jul 1999 15:54:22 +0900,
Seigo Tanimura [EMAIL PROTECTED] said:
tanimura Thus a callout will have an average delay of 0.5/hz = 50ms. This is
5ms, I mean...
Seigo Tanimura [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the
On Thu, 8 Jul 1999 09:54:42 +0100 (BST),
Doug Rabson d...@nlsystems.com said:
dfr If I understand this correctly, you are suggesting that we program timer0
dfr so that we only take interrupts when a finetimer is due to fire? If so,
dfr then it sounds very good. The idea of taking 6000+
On Wed, 14 Jul 1999 15:54:22 +0900,
Seigo Tanimura tanim...@naklab.dnj.ynu.ac.jp said:
tanimura Thus a callout will have an average delay of 0.5/hz = 50ms. This is
5ms, I mean...
Seigo Tanimura tanim...@naklab.dnj.ynu.ac.jp
To Unsubscribe: send mail to majord...@freebsd.org
with
p...@critter.freebsd.dk (Poul-Henning Kamp) writes:
Somebody should study the abilities of the on-cpu APIC for this
for pentium ff. machines.
The local APIC would work very nicely, but I'm not sure that you can
enable it reliably in a non-SMP configuration. AFAIK most BIOSes
don't provide an
But shouldn't you still be able to use the timer in the local apic ?
In message 86k8sajlmz@not.demophon.com, Ville-Pertti Keinonen writes:
p...@critter.freebsd.dk (Poul-Henning Kamp) writes:
Somebody should study the abilities of the on-cpu APIC for this
for pentium ff. machines.
The
p...@critter.freebsd.dk (Poul-Henning Kamp) writes:
But shouldn't you still be able to use the timer in the local apic ?
Did you read the last paragraph in my message?
Here it is again:
It's been a while since I looked at the documentation, but it *might*
be possible that the local APIC
On Thu, 8 Jul 1999 09:54:42 +0100 (BST),
Doug Rabson [EMAIL PROTECTED] said:
dfr If I understand this correctly, you are suggesting that we program timer0
dfr so that we only take interrupts when a finetimer is due to fire? If so,
dfr then it sounds very good. The idea of taking 6000+
this is problematic.
you cannot add a new element before the pending firing because you can't
tell how far into the present trigger you are.
On Thu, 8 Jul 1999, Doug Rabson wrote:
On Thu, 8 Jul 1999, Seigo Tanimura wrote:
On Wed, 7 Jul 1999 19:46:38 -0700 (PDT),
Julian Elischer
On Thu, 8 Jul 1999 09:54:42 +0100 (BST),
Doug Rabson d...@nlsystems.com said:
dfr If I understand this correctly, you are suggesting that we program timer0
dfr so that we only take interrupts when a finetimer is due to fire? If so,
dfr then it sounds very good. The idea of taking 6000+
On Thu, 8 Jul 1999, Seigo Tanimura wrote:
On Thu, 8 Jul 1999 09:54:42 +0100 (BST),
Doug Rabson d...@nlsystems.com said:
dfr If I understand this correctly, you are suggesting that we program timer0
dfr so that we only take interrupts when a finetimer is due to fire? If so,
dfr then it
dfr If I understand this correctly, you are suggesting that we program timer0
dfr so that we only take interrupts when a finetimer is due to fire? If so,
dfr then it sounds very good. The idea of taking 6000+ interrupts/sec made me
dfr uneasy, even though most would return without doing any work.
Somebody should study the abilities of the on-cpu APIC for this
for pentium ff. machines.
In message 199907081527.baa04...@godzilla.zeta.org.au, Bruce Evans writes:
dfr If I understand this correctly, you are suggesting that we program timer0
dfr so that we only take interrupts when a finetimer
13 matches
Mail list logo
