[opensuse] preempt rt and Leap 42.3 kernel
I think there was a discussion about this a while back. But I'm just checking the current consensus. The Leap 42.3 kernel seems not to have the PREEMPT_RT patches applied. Or at least I do not see it in uname -a. Is this correct? I recall that there was some discussion that concluded that the default Linux kernel has most of this as standard, so the patch was no longer needed. Is that the case? -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
No one here interested in PREEMPT_RT and openSUSE? Is there perhaps a
better list for this?
On Thu, Nov 30, 2017 at 3:42 PM, Roger Oberholtzer
I think there was a discussion about this a while back. But I'm just checking the current consensus.
The Leap 42.3 kernel seems not to have the PREEMPT_RT patches applied. Or at least I do not see it in uname -a. Is this correct?
I recall that there was some discussion that concluded that the default Linux kernel has most of this as standard, so the patch was no longer needed. Is that the case?
-- Roger Oberholtzer
-- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2017-12-11 a las 10:32 +0100, Roger Oberholtzer escribió:
No one here interested in PREEMPT_RT and openSUSE? Is there perhaps a better list for this?
I'm curious about it but I know little. - -- Cheers Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlouUdcACgkQja8UbcUWM1w4fAD/b4v8Eljh6VirK+oMO9TNjyT3 zrKIu4DKvxkf/60FOQ0A/2h7TAR40iR+Ri3FuxNMMHAfM8ZQbQtvbjf4BCVMMiVQ =7zoz -----END PGP SIGNATURE-----
On Mon, Dec 11, 2017 at 10:37 AM, Carlos E. R.
No one here interested in PREEMPT_RT and openSUSE? Is there perhaps a better list for this?
I'm curious about it but I know little.
We are exploring making a hardware controller on a Raspberry Pi 3 running openSUSE. It responds to interrupts and, based on them, manipulates some pins and, occasionally, sends off some Ethernet packets. We currently use a slower processor on an embedded card for this. It has so little memory that our app is all that can run. The network stack runs in our application. We would so like to use a real OS and off-load networking to that OS. Also, the development environment on openSUSE is so much nicer. We would be very happy if we could get GPIO IRQs at up to 40 kHz. Our minimal kernel IRQ handler currently does nothing, and we get IRQs at up to 23 kHz. Above that we start to miss them. We are not sure if this is because of the kernel overhead, or because of the Raspberry Pi 3 hardware related to interrupts on the GPIO. I am exploring if there is anything we might be able to do to improve the Linux kernel part of the equation. We will try to keep this as a kernel driver, so we can at least eliminate the need for a context switch. At least not very often (e.g., 25 Hz). -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2017-12-11 a las 10:57 +0100, Roger Oberholtzer escribió:
On Mon, Dec 11, 2017 at 10:37 AM, Carlos E. R. <> wrote:
No one here interested in PREEMPT_RT and openSUSE? Is there perhaps a better list for this?
I'm curious about it but I know little.
We are exploring making a hardware controller on a Raspberry Pi 3 running openSUSE. It responds to interrupts and, based on them, manipulates some pins and, occasionally, sends off some Ethernet packets. We currently use a slower processor on an embedded card for this. It has so little memory that our app is all that can run. The network stack runs in our application. We would so like to use a real OS and off-load networking to that OS. Also, the development environment on openSUSE is so much nicer.
We would be very happy if we could get GPIO IRQs at up to 40 kHz. Our minimal kernel IRQ handler currently does nothing, and we get IRQs at up to 23 kHz. Above that we start to miss them. We are not sure if this is because of the kernel overhead, or because of the Raspberry Pi 3 hardware related to interrupts on the GPIO. I am exploring if there is anything we might be able to do to improve the Linux kernel part of the equation. We will try to keep this as a kernel driver, so we can at least eliminate the need for a context switch. At least not very often (e.g., 25 Hz).
Very interesting stuff :-) But a RT system does not guarantee speed; what it guarantees is that things are handled within a known time frame. In theory. I don't know how to calculate that time. - -- Cheers Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlouXcEACgkQja8UbcUWM1yVKQD/SXBPD9iZ4qhSoA650LIpj7pq nS81yxhzKQk431m+/ecA/2aPOHtTE9Q3NR+I4Twu2v4ocf/7Y/sQm+DQmQlfIOrX =7vBi -----END PGP SIGNATURE-----
On Mon, Dec 11, 2017 at 11:28 AM, Carlos E. R.
Very interesting stuff :-)
We use openSUSE in many unusual places...
But a RT system does not guarantee speed; what it guarantees is that things are handled within a known time frame. In theory. I don't know how to calculate that time.
Latency is related to speed. If latency is long, speed will be slow. If latency is short, speed could potentially be faster. One way to measure latency is to toggle the IRQ line via a GPIO output line. Record when the toggle was done, and the time when the IRQ function starts. We are getting ready to do that. I hear reports of between 10 and 70 µs latency are expected. What we are trying to sort out is how to measure the latency after the interrupt handler completes. That is, when is everything okay for the next interrupt to occur? -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2017-12-11 a las 12:58 +0100, Roger Oberholtzer escribió:
On Mon, Dec 11, 2017 at 11:28 AM, Carlos E. R.
Very interesting stuff :-)
We use openSUSE in many unusual places...
But a RT system does not guarantee speed; what it guarantees is that things are handled within a known time frame. In theory. I don't know how to calculate that time.
Latency is related to speed. If latency is long, speed will be slow. If latency is short, speed could potentially be faster.
No, that is not the point with RT. You can have a RT system with a guaranteed response time of one minute. It is still RT, as long as all requests are attended and completed within one minute of each. You may want a fast RT system, but that is another thing ;-)
One way to measure latency is to toggle the IRQ line via a GPIO output line. Record when the toggle was done, and the time when the IRQ function starts. We are getting ready to do that. I hear reports of between 10 and 70 µs latency are expected. What we are trying to sort out is how to measure the latency after the interrupt handler completes. That is, when is everything okay for the next interrupt to occur?
I did that thing once, long ago. - -- Cheers Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAloudQIACgkQja8UbcUWM1xBggD/SK7vqzpCIovYrQKADhT1HPEc ae4TooIuR+AhceXZS2gA/ji1SH48b5CnJ34lpwM8aTj926/tMWwPOzhPubVzyIgD =tL5Z -----END PGP SIGNATURE-----
On Mon, Dec 11, 2017 at 1:07 PM, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
El 2017-12-11 a las 12:58 +0100, Roger Oberholtzer escribió:
On Mon, Dec 11, 2017 at 11:28 AM, Carlos E. R.
Very interesting stuff :-)
We use openSUSE in many unusual places...
But a RT system does not guarantee speed; what it guarantees is that things are handled within a known time frame. In theory. I don't know how to calculate that time.
Latency is related to speed. If latency is long, speed will be slow. If latency is short, speed could potentially be faster.
No, that is not the point with RT. You can have a RT system with a guaranteed response time of one minute. It is still RT, as long as all requests are attended and completed within one minute of each.
I know that real time usually refers to things happening within a predictable time frame. It need not be fast. Just within an acceptable predictable time. Real time typically reduces the jitter in responding to things. We have a suspicion that jitter may cause interrupts to be lost. If an interrupt sometimes takes longer to be handled, more interrupts of that type might be lost. Especially if more than one interrupt happens in the time a single interrupt handler runs.
You may want a fast RT system, but that is another thing ;-)
We want fast. And the question is: what is reasonable to expect with a Linux kernel on a Raspberry Pi 3 and it's GPIO interrupt hardware?
One way to measure latency is to toggle the IRQ line via a GPIO output line. Record when the toggle was done, and the time when the IRQ function starts. We are getting ready to do that. I hear reports of between 10 and 70 µs latency are expected. What we are trying to sort out is how to measure the latency after the interrupt handler completes. That is, when is everything okay for the next interrupt to occur?
I did that thing once, long ago.
Fun stuff. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2017-12-11 a las 13:35 +0100, Roger Oberholtzer escribió:
On Mon, Dec 11, 2017 at 1:07 PM, Carlos E. R. <> wrote:
El 2017-12-11 a las 12:58 +0100, Roger Oberholtzer escribió:
Real time typically reduces the jitter in responding to things. We have a suspicion that jitter may cause interrupts to be lost. If an interrupt sometimes takes longer to be handled, more interrupts of that type might be lost. Especially if more than one interrupt happens in the time a single interrupt handler runs.
Yes. They might be queed. With a RT kernel I guess you could have a fast int handler, doing the minimum, and another process, in RT, handling the rest as viable.
You may want a fast RT system, but that is another thing ;-)
We want fast. And the question is: what is reasonable to expect with a Linux kernel on a Raspberry Pi 3 and it's GPIO interrupt hardware?
I wish I knew :-)
One way to measure latency is to toggle the IRQ line via a GPIO output line. Record when the toggle was done, and the time when the IRQ function starts. We are getting ready to do that. I hear reports of between 10 and 70 µs latency are expected. What we are trying to sort out is how to measure the latency after the interrupt handler completes. That is, when is everything okay for the next interrupt to occur?
I did that thing once, long ago.
Fun stuff.
You bet :-) - -- Cheers Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlougNIACgkQja8UbcUWM1ysPAD/Z/yl8rxTG9b3nc1KskBNvTwg PIvQfthxc+DvGxJXYqIA/j7RNa5WEkMJtaQgDqTjTmPZMmjRP5A2wXw5r/CjTxEt =+eEu -----END PGP SIGNATURE-----
On Mon, Dec 11, 2017 at 1:57 PM, Carlos E. R.
Real time typically reduces the jitter in responding to things. We have a suspicion that jitter may cause interrupts to be lost. If an interrupt sometimes takes longer to be handled, more interrupts of that type might be lost. Especially if more than one interrupt happens in the time a single interrupt handler runs.
Yes. They might be queed.
But if the same interrupt happens more than once while a previous one is still being serviced, maybe the hardware only shows that it has happened one more time. As we need to count these, this is not a workable solution. Some parts of the Raspberry PI3 are very poorly documented.
With a RT kernel I guess you could have a fast int handler, doing the minimum, and another process, in RT, handling the rest as viable.
We use the top/bottom half interrupt routine method. The 50 kHz stuff is actually quite minimal and is maintained in the top half handler. At a much slower frequency (30 Hz) the slow stuff can be done in the bottom half handler. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 11 Dec 2017 10:57:29 +0100
Roger Oberholtzer
On Mon, Dec 11, 2017 at 10:37 AM, Carlos E. R.
wrote: No one here interested in PREEMPT_RT and openSUSE? Is there perhaps a better list for this?
I'm curious about it but I know little.
We are exploring making a hardware controller on a Raspberry Pi 3 running openSUSE. It responds to interrupts and, based on them, manipulates some pins and, occasionally, sends off some Ethernet packets. We currently use a slower processor on an embedded card for this. It has so little memory that our app is all that can run. The network stack runs in our application. We would so like to use a real OS and off-load networking to that OS. Also, the development environment on openSUSE is so much nicer.
We would be very happy if we could get GPIO IRQs at up to 40 kHz. Our minimal kernel IRQ handler currently does nothing, and we get IRQs at up to 23 kHz. Above that we start to miss them. We are not sure if this is because of the kernel overhead, or because of the Raspberry Pi 3 hardware related to interrupts on the GPIO. I am exploring if there is anything we might be able to do to improve the Linux kernel part of the equation. We will try to keep this as a kernel driver, so we can at least eliminate the need for a context switch. At least not very often (e.g., 25 Hz).
I would guess a Pi list or forum might be a better place to ask. The kernel is largely shared amongst distributions I think? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Dec 11, 2017 at 12:33 PM, Dave Howorth
On Mon, 11 Dec 2017 10:57:29 +0100 Roger Oberholtzer
wrote:
I would guess a Pi list or forum might be a better place to ask. The kernel is largely shared amongst distributions I think?
I have been sniffing around there as well. I started on the openSUSE ARM list. Not much in terms of response. So I tried here. Seems that people are looking at how quickly things get in to a python script, or how fast one can manipulate the GPIO pins (not receive interrupts). -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 11 Dec 2017 12:51:28 +0100
Roger Oberholtzer
On Mon, Dec 11, 2017 at 12:33 PM, Dave Howorth
wrote: On Mon, 11 Dec 2017 10:57:29 +0100 Roger Oberholtzer
wrote: I would guess a Pi list or forum might be a better place to ask. The kernel is largely shared amongst distributions I think?
I have been sniffing around there as well. I started on the openSUSE ARM list. Not much in terms of response. So I tried here.
Seems that people are looking at how quickly things get in to a python script, or how fast one can manipulate the GPIO pins (not receive interrupts).
I just did a google for 'raspberry pi interrupt speed linux RT' There were a few possibly interesting links but I haven't looked at them all. The best I did look at was https://medium.com/@metebalci/latency-of-raspberry-pi-3-on-standard-and-real... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Dec 11, 2017 at 2:10 PM, Dave Howorth
On Mon, 11 Dec 2017 12:51:28 +0100 Roger Oberholtzer
wrote: On Mon, Dec 11, 2017 at 12:33 PM, Dave Howorth
wrote: On Mon, 11 Dec 2017 10:57:29 +0100 Roger Oberholtzer
wrote: I would guess a Pi list or forum might be a better place to ask. The kernel is largely shared amongst distributions I think?
I have been sniffing around there as well. I started on the openSUSE ARM list. Not much in terms of response. So I tried here.
Seems that people are looking at how quickly things get in to a python script, or how fast one can manipulate the GPIO pins (not receive interrupts).
I just did a google for 'raspberry pi interrupt speed linux RT' There were a few possibly interesting links but I haven't looked at them all. The best I did look at was
https://medium.com/@metebalci/latency-of-raspberry-pi-3-on-standard-and-real...
I have seen this, as well as similar latency tests. This info seems consistent with what I saw. Some have demonstrated that the latency outliers decrease significantly when the PREMPT_RT patches are applied. This is what prompted my original question. Next I have to see if I can get an openSUSE kernel for Tumbleweed/ARM/RaspberryPI3 that has the PREMPT_RT patches applied. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Mon, Dec 11, 2017 at 2:10 PM, Dave Howorth
wrote: On Mon, 11 Dec 2017 12:51:28 +0100 Roger Oberholtzer
wrote: On Mon, Dec 11, 2017 at 12:33 PM, Dave Howorth
wrote: On Mon, 11 Dec 2017 10:57:29 +0100 Roger Oberholtzer
wrote: I would guess a Pi list or forum might be a better place to ask. The kernel is largely shared amongst distributions I think?
I have been sniffing around there as well. I started on the openSUSE ARM list. Not much in terms of response. So I tried here.
Seems that people are looking at how quickly things get in to a python script, or how fast one can manipulate the GPIO pins (not receive interrupts).
I just did a google for 'raspberry pi interrupt speed linux RT' There were a few possibly interesting links but I haven't looked at them all. The best I did look at was
https://medium.com/@metebalci/latency-of-raspberry-pi-3-on-standard-and-real...
I have seen this, as well as similar latency tests. This info seems consistent with what I saw. Some have demonstrated that the latency outliers decrease significantly when the PREMPT_RT patches are applied. This is what prompted my original question.
Next I have to see if I can get an openSUSE kernel for Tumbleweed/ARM/RaspberryPI3 that has the PREMPT_RT patches applied.
It shouldn't be too difficult to start with a standard kernel configured for ARM and then apply the patch yourself? -- Per Jessen, Zürich (6.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Dec 11, 2017 at 4:03 PM, Per Jessen
It shouldn't be too difficult to start with a standard kernel configured for ARM and then apply the patch yourself?
It's on my list. I need to see if there are any other patches applied for the Raspberry Pi 3 on Tumbleweed. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (4)
-
Carlos E. R.
-
Dave Howorth
-
Per Jessen
-
Roger Oberholtzer