Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer)
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+ interrupts/sec made me dfr uneasy, even though most would return without doing any work. I have been reading the i8254 data sheet for another couple of days, to find a new problem. If we have a callout to be made before the timer fires, the counter needs to be reprogrammed with a new value. We cannot reload the new counter value immediately; an i8254 does not load the new value until the currrent period finishes (ie the timer fires) or the gate rises. Thus a callout will have an average delay of 0.5/hz = 50ms. This is too long for a timeout in microseconds. Seigo Tanimura [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer)
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 body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer)
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+ interrupts/sec made me dfr uneasy, even though most would return without doing any work. I have been reading the i8254 data sheet for another couple of days, to find a new problem. If we have a callout to be made before the timer fires, the counter needs to be reprogrammed with a new value. We cannot reload the new counter value immediately; an i8254 does not load the new value until the currrent period finishes (ie the timer fires) or the gate rises. Thus a callout will have an average delay of 0.5/hz = 50ms. This is too long for a timeout in microseconds. Seigo Tanimura tanim...@naklab.dnj.ynu.ac.jp To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer)
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 unsubscribe freebsd-hackers in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer)
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 MP config at all unless you have multiple CPUs present. If you don't have an MP config, you can't set up the redirection tables. And if you have a non-SMP chipset, you can't route interrupts at all, since you won't have an APIC bus on your motherboard or an I/O APIC for the real interrupts. It's been a while since I looked at the documentation, but it *might* be possible that the local APIC timers would work without using APIC interrupt routing. IIRC the timers are simply programmed with the IDT vector number to generate as an interrupt. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer)
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 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 MP config at all unless you have multiple CPUs present. If you don't have an MP config, you can't set up the redirection tables. And if you have a non-SMP chipset, you can't route interrupts at all, since you won't have an APIC bus on your motherboard or an I/O APIC for the real interrupts. It's been a while since I looked at the documentation, but it *might* be possible that the local APIC timers would work without using APIC interrupt routing. IIRC the timers are simply programmed with the IDT vector number to generate as an interrupt. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer)
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 timers would work without using APIC interrupt routing. IIRC the timers are simply programmed with the IDT vector number to generate as an interrupt. I haven't tried it, I don't know what would happen. If someone else knows (or has a chance to try it soon), please comment. Even if it works, using the feature would probably have to rely on undocumented behavior. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer)
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+ interrupts/sec made me dfr uneasy, even though most would return without doing any work. Yes, that is what I am doing now. And some further discussion... t' \sum_(k=0)^(j) dt_rem(c_k) where the right hand side of the inequality is the time span after which the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). If t' is less than dt_rem(c_0) then we have no feasible j. This is the case in which we must reaquire_timer0() using t'. Then, after interting c', dt_rem(c_1) is updated to be (dt_rem(c_1) - (time elapsed since the last aquire_timer0())), so that c_1 can be armed later. There is one problem in this method. acquire_timer0() is only implemented for i386. We would need to write something equivalent for alpha... Seigo Tanimura [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer)
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 [EMAIL PROTECTED] said: julian With your scheme the clock needs to be always running at elevated speed. julian Possibly you might have a startup routine that turns on the elevated julian frequency, (basically does an 'aquire_timer0()' ) I would say that you julian would have more success in implementing your finetimer() by using julian "aquiretimer0" than the other way around. I agree that acquire_timer0() would give more freedom to the ticks to callout. Then I tried figuring out how to manage multiple callouts using acquire_timer0(), which is something like below. Let C the callout queue, and c_i a callout. (0 = i I) Next define f(c_i) as the callout function of c_i, and dt_rem(c_i) the time span between c_(i-1) and c_i. (dt_rem(c_-1) is defined as zero) We use the time span to avoid traversing though the queue to update the time tags on the callouts. (footnote: I'd better write in TeX :-) Queueing a new callout c' to be made in t' involves a problem to find the maximum j (which is an integer, j = 0) satisfying a constraint t' \sum_(k=0)^(j) dt_rem(c_k) where the right hand side of the inequality is the time span after which the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). In clkintr(), we dequeue c_0 from C, and make a callout to f(c_0). Then acquire_timer0() is called once more with the new dt_rem(c_0). dt_rem(c_i) is the difference of callout times, so they need not be updated on every clkintr(). Although the computational cost in clkintr() is generaly O(1), the queueing cost is O(I). Not sure whether we can reduce it or not (will it really make a trouble?) How does it sound? If I understand this correctly, you are suggesting that we program timer0 so that we only take interrupts when a finetimer is due to fire? If so, then it sounds very good. The idea of taking 6000+ interrupts/sec made me uneasy, even though most would return without doing any work. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd.Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer)
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+ interrupts/sec made me dfr uneasy, even though most would return without doing any work. Yes, that is what I am doing now. And some further discussion... t' \sum_(k=0)^(j) dt_rem(c_k) where the right hand side of the inequality is the time span after which the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). If t' is less than dt_rem(c_0) then we have no feasible j. This is the case in which we must reaquire_timer0() using t'. Then, after interting c', dt_rem(c_1) is updated to be (dt_rem(c_1) - (time elapsed since the last aquire_timer0())), so that c_1 can be armed later. There is one problem in this method. acquire_timer0() is only implemented for i386. We would need to write something equivalent for alpha... Seigo Tanimura tanim...@naklab.dnj.ynu.ac.jp To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer)
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 sounds very good. The idea of taking 6000+ interrupts/sec made me dfr uneasy, even though most would return without doing any work. Yes, that is what I am doing now. And some further discussion... t' \sum_(k=0)^(j) dt_rem(c_k) where the right hand side of the inequality is the time span after which the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). If t' is less than dt_rem(c_0) then we have no feasible j. This is the case in which we must reaquire_timer0() using t'. Then, after interting c', dt_rem(c_1) is updated to be (dt_rem(c_1) - (time elapsed since the last aquire_timer0())), so that c_1 can be armed later. There is one problem in this method. acquire_timer0() is only implemented for i386. We would need to write something equivalent for alpha... The timer hardware on the alpha is essentially the same but the interrupts are wired up differently. I'm not sure how hard it would be to get timer0 working but I think it should be possible. The alphas tend to run the main clock quite fast (typically 1024hz) so the granularity of timing is better but probably not good enough for midi or pca. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer)
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. 6000+ interrupts/sec is not many, unless it is done all the time. A 486/33 can handle about 5 (16000 for pcaudio + 3 * 11520 for sio's). There is one problem in this method. acquire_timer0() is only implemented for i386. We would need to write something equivalent for alpha... This is a serious problem. acquire_timer0() is currently disabled even for i386's when the i8254 is used for timecounting. This is not hard to fix (the hooks into clkintr() work even better with timecounters since it is not necessary to resynchronise clock interrupts after a state change), but an i8254 interrupt frequency of 16000 Hz is too fast to be used routinely if the i8254 is being used for timecounting (even if the CPU can keep up with the interrupts, the overflow heuristics in i8254_get_timecount() may break down). Other systems may have even more limitations on the timecounters. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer)
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 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. 6000+ interrupts/sec is not many, unless it is done all the time. A 486/33 can handle about 5 (16000 for pcaudio + 3 * 11520 for sio's). There is one problem in this method. acquire_timer0() is only implemented for i386. We would need to write something equivalent for alpha... This is a serious problem. acquire_timer0() is currently disabled even for i386's when the i8254 is used for timecounting. This is not hard to fix (the hooks into clkintr() work even better with timecounters since it is not necessary to resynchronise clock interrupts after a state change), but an i8254 interrupt frequency of 16000 Hz is too fast to be used routinely if the i8254 is being used for timecounting (even if the CPU can keep up with the interrupts, the overflow heuristics in i8254_get_timecount() may break down). Other systems may have even more limitations on the timecounters. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
