Re: [rtl] RTL + Low Latency patch interference?
Wed, 17 Jan 2001 Cort Dougan wrote: > } Problem is, I need an understanding of how useful > } this would be to people. My requirements troll > } on linux-audio-dev doesn't seem to have elicited > } a response. > } > } Do we need it? If so, how bad? > > Be sure to send this to the FB console list. They've been looking for a > solution for over a year. What about retrace sync? (Which is not in the mainstream fbcon, as it's inherently horrible code on most cards.) I have a solution that "kind of" works even if SCHED_FIFO threads are allowed to preempt the retrace polling loop every now and then - the only impact will be that whoever uses the retrace sync ioctl will (obviously) return a little late, depending on how nasty the SCHED_FIFO threads are. (Not if the video thread has higher priority, of course!) The current implementation simply uses the Pentium performance counter to keep track of when the next retrace should occur, syncing the internal "milliframe" time to the video card whenever it actually gets a chance to see the retrace bit. This could probably be extended to use some kind of kernel timers, but I'm not sure how reliable that would be from the video perspective. (When using real hardware pageflipping as opposed to blitting, you *can't* be late. If you are, you'll simply miss a frame!) Then again, as we're talking about lowlatency here, this could actually work pretty well if done right. //David ..- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `--> http://www.linuxaudiodev.com/maia -' ..- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `--> [EMAIL PROTECTED] -' -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
} Problem is, I need an understanding of how useful } this would be to people. My requirements troll } on linux-audio-dev doesn't seem to have elicited } a response. } } Do we need it? If so, how bad? Be sure to send this to the FB console list. They've been looking for a solution for over a year. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
Wed, 17 Jan 2001 Andrew Morton wrote: > Cort Dougan wrote: > > > > > > Note that this is x86. If your system requires FBCon (PPC and sparc) you > > need to learn to live with 810ms (yes, 810 milliseconds) worst-case with the > > rage128 card (similar performance for other video cards) with the linux > > low-latency patches. > > > > I took a look at this crap a few days ago. It's actually quite > straightforward to fix. > > - Turn the console_lock into a semaphore > - If a printk comes in interrupt context and > the semaphore is free, grab it and proceed > - If in_interrupt and the semephore is not > free, buffer the printk output and let > whoever holds the semaphore spit out > the buffered data when it's about to > return from printk. > > Easy. > > Problem is, I need an understanding of how useful > this would be to people. My requirements troll > on linux-audio-dev doesn't seem to have elicited > a response. > > Do we need it? If so, how bad? Well, how messy is the fix, actually? As I said (somewhere else), I'm using fbdev on most of my machines (the ones with *real* monitors, more specifically), so I'd at least want fbdev to be nice when in the background. It would be really nice if fbdev was entirely RT safe, of course, but I can't claim that I *really* need it, as I'm not actively developing anything to run mainly on fbdev. (I'm using GGI or SDL for most things, so I can run the GUIs on almost anything.) This may well change, though, as I'm more fond of panel based GUIs than windowing when it comes to dedicated machines like the ones I have in mind for my first serious audio applications. (Stand-alone synth, direct-from-disk sampler, recorder, FX box etc.) X will waste a great deal of resource to no avail for such GUIs. In short, I *want* it, but I can't say that I really *need* it, at least not yet. //David ..- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `--> http://www.linuxaudiodev.com/maia -' ..- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `--> [EMAIL PROTECTED] -' -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
Tue, 16 Jan 2001 Cort Dougan wrote: > } Actually, our practical experiences with the lowlatency patch is that you can > } use it for hard real time as well, as long as a worst case latency of 1 ms is > } acceptable. For multimedia (which is nearly always using buffered streaming of > } various kinds, all the way down to the hardware level), this is excellent. All > } we need is to make sure that buffers are processed in time. Sub 30 µs worst > } case latency doesn't result in a significant performance improvement, not even > } for audio. > > Note that this is x86. If your system requires FBCon (PPC and sparc) you > need to learn to live with 810ms (yes, 810 milliseconds) worst-case with the > rage128 card (similar performance for other video cards) with the linux > low-latency patches. That's almost impressive! ;-) What's the fbcon driver actually doing!? And this isn't very fun on x86 either, actually; I think using fbcon while running lowlatency threads is still on the DDT list. Andrew Morton seems to have a solution in the works, though, if lowlatency people really care about fbcon... > Andrew does have FBCon listed on the "don't do this" list but that does > rule out several systems. I'm not sure about that; does fbcon cause trouble on PPC even when X is running the display? (This doesn't seem to be the case with my Celeron 333 with a Permedia-2 based card running fbdev at least, but I have yet to test the 933/G400 system seriously.) > That being said, the low-latency patches are a nice complement to RTLinux. > RTLinux provides hard real-time and _guarantees_ while the low-latency "Guarantee" is a rather relative term... RTL and RTAI are capable of giving worst case guarantees in the sub 30 µs range on most systems, while lowlatency can't do better than about 1 ms - both figures derived from real life setups, and entirely depending on the hardware. It *might* be easier to set up a reliable 30 µs RTL system than a reliable 1 ms lowlatency system, but I'm not sure. Fire up a nasty X server, or enable the powermanagement of a crappy mainboard, and both systems will start missing deadlines. The most significant differences between RTL and lowlatency - apart from the order of magnitude of the latency - is how complicated it is to figure out a reliable worst case latency figure, and the latency spread. Lowlatency depends on a lot more code, and is therefore harder to test and predict, and also has a bigger worst case/average latency ratio than RTL or RTAI. That said, it's not correct to dismiss Linux/lowlatency as not capable of hard real time - unless you're going to disiss *every* real life OS running on any hardware. Hardware can fry, the OS can crash, the OS or the hardware can case a missed deadline, or the RT software can crash - it's just a matter of what kind of probabilities you're dealing with, and how close to the average latency you have to push the system. > patches give good response for Linux processes. Most RTLinux based systems > are built from a combination of RTLinux tasks and traditional Linux tasks, > after all. Yes, and even on a system on which the lowlatency patch doesn't work all the way down to the singe ms, you still get very firm real time in user space. A program that's tuned to miss less than a few percent of the deadlines on a standard kernel will probably never miss a deadline even on that system, and *never* on a fully working lowlatency system. //David ..- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `--> http://www.linuxaudiodev.com/maia -' ..- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `--> [EMAIL PROTECTED] -' -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
Cort Dougan wrote: > > > Note that this is x86. If your system requires FBCon (PPC and sparc) you > need to learn to live with 810ms (yes, 810 milliseconds) worst-case with the > rage128 card (similar performance for other video cards) with the linux > low-latency patches. > I took a look at this crap a few days ago. It's actually quite straightforward to fix. - Turn the console_lock into a semaphore - If a printk comes in interrupt context and the semaphore is free, grab it and proceed - If in_interrupt and the semephore is not free, buffer the printk output and let whoever holds the semaphore spit out the buffered data when it's about to return from printk. Easy. Problem is, I need an understanding of how useful this would be to people. My requirements troll on linux-audio-dev doesn't seem to have elicited a response. Do we need it? If so, how bad? -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
Nathan Paul Simons wrote: > > It's just that it seems like > applications that require low latency could be deftly handled by using hard > real time, and the low latency patch has a lot of provisos for its use. There > was much discussion on the Linux kernel list about the issues that the low > latency patch raised. While many people said that it Worked For Them(tm), it > looked like the patch would not be compatible with many drivers and perhaps > even platforms (did anyone ever test the patch on anything besides ia32?). The faery dust should Just Work on RTL. This problem report surprises me.. It should also work on non-x86, but the single non-x86 report (PPC) is unpromising. Something Wierd is happening.. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
Tue, 16 Jan 2001 Nathan Paul Simons wrote: > On Tue, Jan 16, 2001 at 08:38:30AM -0700, [EMAIL PROTECTED] wrote: > > You could have asked me: aside from getting wierd OS failures (which is > > always fun) there is a really interesting area in which "soft" realtime > > applications interact with hard realtime applications: e.g. hard RT > > collects frames, feeds them to a soft RT which does some mixing, and hard > > RT outputs. > > I think that the area in which hard and soft RT cooperate is one of the most > > important research&development areas in OS. > > I stand humbled. My apologies if I seemed overly negative towards the > question of using the low latency patch. It's just that it seems like > applications that require low latency could be deftly handled by using hard > real time, and the low latency patch has a lot of provisos for its use. There > was much discussion on the Linux kernel list about the issues that the low > latency patch raised. While many people said that it Worked For Them(tm), it > looked like the patch would not be compatible with many drivers and perhaps > even platforms (did anyone ever test the patch on anything besides ia32?). Actually, apart from some versions of the lowlatency patch not really working (ie not covering all kernel calls), and some user space drivers (like XFree86) and applications having built-in deadlocks that are exposed only if they're running SCHED_FIFO, there's nothing much to worry about. Use kernel drivers, libraries and other stuff as much as you like, but keep in mind that (just as with RTL, RTAI, QNX or whatever) if you access something that's inherently nondeterministic, that will impact the performance of your code. //David ..- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `--> http://www.linuxaudiodev.com/maia -' ..- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `--> [EMAIL PROTECTED] -' -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
Tue, 16 Jan 2001 [EMAIL PROTECTED] wrote: > On Tue, Jan 16, 2001 at 08:17:00AM -0700, John Regehr wrote: > > The point is that real-time applications have widely varying > > requirements and, as people have been discussing recently, not everybody > > wants to stuff their app into the more restricted and difficult > > enviroment. > > I want to point out that (A) RTLinux programming environment is not so > difficult and (B) the low latency patches are not so unrestricted. > Andrew Morton (who seems to have been the second Linux developer to turn > into an entire programming team) has a list of "don't do that"'s to > accompany his patch. Indeed, some versions of the patch are not even practically usable for real applications. However, the DDT lists were mainly a "lowlatency on 2.3.4" storry, and were the result of cutting the patch down to a level of ugliness that Linus would accept in the mainstream kernel. Also, that was before some plain bad code was fixed. This code had impact on performance and SMP in particular, as well as on worst case latencies, and these fixed, the DDT list will be more or less eliminated, while still alowing a minimal number of "ugly" conditional reschedule points to guarantee excellent performance under all kinds of system stress. BTW, looking at the latest lowlatency versions for the latest 2.4 kernels, it seems that Linux 2.4 is approaching a level where the lowlatency patch won't even be needed. (Thanks to the work related to SMP performance, mostly.) According to another post I read somewhere, Mingo's *real* lowlatency patch ported to 2.4 keeps the worst case latency on some of the test systems below 0.35 ms, IIRC. Almost 3 times better than the original lowlatency patch on 2.2.10, that is. :-) > > One drawback of running soft real-time apps in user space while running > > hard real-time apps in RTLinux is that RTLinux will become a source of > > latency for regular Linux. In other words, if a RTLinux task has a WCET > > of 1ms, then the worst-cast dispatch latency of regular Linux will be > > increased by 1ms. > > Just as the worst-case dispatch latency of SCHED_OTHER processes in > Linux gets worse by the worst case compute time of and SCHED_FIFO process. The same goes for RT threads running under the same scheduler in any environment, unless some kind of high frequency time sharing is used. Lower priority threads always depend on the higher prio threads not to increase their worst case scheduling latency too much. (See why multiuser systems generally don't provide real time scheduling for all users?) //David ..- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `--> http://www.linuxaudiodev.com/maia -' ..- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `--> [EMAIL PROTECTED] -' -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
Tue, 16 Jan 2001 [EMAIL PROTECTED] wrote: > On Tue, Jan 16, 2001 at 03:25:12AM -0700, Nathan Paul Simons wrote: > > On Tue, Jan 16, 2001 at 10:26:36AM +0100, Bart Thissen wrote: > > > Does any body has experience with the low latency kernel patch and > > > RTL together? I did try this combination once, and found serious > > > problems under heavy load, maybe related to bad memory. > > > > Excuse me for asking, but *why* would you want to do this? If you > > You could have asked me: aside from getting wierd OS failures (which is > always fun) there is a really interesting area in which "soft" realtime > applications interact with hard realtime applications: e.g. hard RT > collects frames, feeds them to a soft RT which does some mixing, and hard > RT outputs. > I think that the area in which hard and soft RT cooperate is one of the most > important research&development areas in OS. Low latency signal processing on SMP machines and clusters seem to be one application for this kind of solutions. Without RTL or similar for some kind of central engine core, the latencies of Linux/lowlatency would multiply with the number of CPUs or even worse, which is not acceptable. I'll do more research in that are when I have some fun software to make use of the power. :-) //David ..- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `--> http://www.linuxaudiodev.com/maia -' ..- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `--> [EMAIL PROTECTED] -' -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
Tue, 16 Jan 2001 [EMAIL PROTECTED] wrote: > On Tue, Jan 16, 2001 at 10:10:53AM -0700, John Regehr wrote: > > > On Tue, Jan 16, 2001 at 08:17:00AM -0700, John Regehr wrote: > > > > The point is that real-time applications have widely varying > > > > requirements and, as people have been discussing recently, not everybody > > > > wants to stuff their app into the more restricted and difficult > > > > enviroment. > > > > > > I want to point out that (A) RTLinux programming environment is not so > > > difficult and > > > > I agree that it's not that hard, but it does raise the bar somewhat. > > The user/kernel boundary is there for a reason, after all: to prevent > > buggy applications from corrupting each other or the system, and to make > > it possible to reclaim all resources when an app terminates abnormally. > > > > That said, the real-time signals in RTLinux 3 look really cool, and they > > are a nice step towards providing a friendlier programming model. > > > > Thanks. We have a funny message to put out: on the one hand RTL > programming requires some skill level but on the other hand, I don't want > people to automatically assume you need to be a kernel hacker to write > RTL code. Or; "It's not hard to write RTL code, but *don't* do anything wrong!" ;-) Well, basically, it's the same problem as with the C64, Atari ST, Amiga, Mac and many other machines before we got MMUs: The APIs may be incredibly nice and simple, but a pointer bug can still blow you system sky high. Those machines were not exactly hard to program, but there were less room for cheating and generally bad habits, such as ignoring return codes, not releasing used resources when quitting etc. //David ..- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `--> http://www.linuxaudiodev.com/maia -' ..- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `--> [EMAIL PROTECTED] -' -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
} Actually, our practical experiences with the lowlatency patch is that you can } use it for hard real time as well, as long as a worst case latency of 1 ms is } acceptable. For multimedia (which is nearly always using buffered streaming of } various kinds, all the way down to the hardware level), this is excellent. All } we need is to make sure that buffers are processed in time. Sub 30 µs worst } case latency doesn't result in a significant performance improvement, not even } for audio. Note that this is x86. If your system requires FBCon (PPC and sparc) you need to learn to live with 810ms (yes, 810 milliseconds) worst-case with the rage128 card (similar performance for other video cards) with the linux low-latency patches. Andrew does have FBCon listed on the "don't do this" list but that does rule out several systems. That being said, the low-latency patches are a nice complement to RTLinux. RTLinux provides hard real-time and _guarantees_ while the low-latency patches give good response for Linux processes. Most RTLinux based systems are built from a combination of RTLinux tasks and traditional Linux tasks, after all. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
Tue, 16 Jan 2001 Bart Thissen wrote: [...] > > Don't know if there are any adverse effects > > the other way around, since I haven't tried this, since I don't see the point. > > > If the low latency patch 'magic feary dust' works well, a lot of non-hardrealtime > tasks can stay in user space, Actually, our practical experiences with the lowlatency patch is that you can use it for hard real time as well, as long as a worst case latency of 1 ms is acceptable. For multimedia (which is nearly always using buffered streaming of various kinds, all the way down to the hardware level), this is excellent. All we need is to make sure that buffers are processed in time. Sub 30 µs worst case latency doesn't result in a significant performance improvement, not even for audio. //David ..- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `--> http://www.linuxaudiodev.com/maia -' ..- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `--> [EMAIL PROTECTED] -' -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
Tue, 16 Jan 2001 Nathan Paul Simons wrote: > On Tue, Jan 16, 2001 at 10:26:36AM +0100, Bart Thissen wrote: > > Does any body has experience with the low latency kernel patch and > > RTL together? I did try this combination once, and found serious > > problems under heavy load, maybe related to bad memory. > > Excuse me for asking, but *why* would you want to do this? If you > have RTLinux you get hard real-time guarantees, which can be used in the same > way low latency can. No. You can't use Linux drivers from within RTL or RTAI without getting the same latency problems as standard Linux user space threads. This renders RTL and RTAI virtually useless for multimedia programming, unless you want to port all drivers you need no actual RTL. (I was headed in that direction until the lowlatency patch arrived, BTW.) > As I remember, the low latency patch just sprinkled > schedule() randomly on the kernel source like magic faery dust. Not exactly randomly; especially not in the latest versions. They're inserted in places where the kernel stays for "ages" occasionally, so that SCHED_FIFO threads can be scheduled within at most 1 ms, rather than up to 100 ms later, or worse. Not magic and not beautiful, but it upgrades Linux from "entirely worthless" to "totally superior" WRT serious real time multimedia. > Shouldn't > make a damn bit of difference to RTLinux, since it preempts the regular > Linux kernel anytime it wants. Don't know if there are any adverse effects > the other way around, since I haven't tried this, since I don't see the point. Right, it shouldn't make any difference to RTL, but it makes all the difference to code running in Linux threads - including any Linux code that RTL threads use to interface with Linux. An excellent example of why one might want to use both RTL and lowlatency would be a Linux based arcade machine, game console or other serious gaming machine. To get anything like the animation quality you see on consoles and arcade machines, you need video refresh rate synchronization, full frame rate and double buffering. To guarantee full frame rate, you need to make sure that the graphics engine gets the CPU time it needs *when* it needs it. It also needs to use various multimedio drivers, which also need their CPU time at the right times. Linux/lowlatency is an excellent solution for that. Further, due to stupid design of the majority of video cards, retrace synchronization isn't as simple as it should be. You need to poll certain ports or registers for the "retrace bit", or similar, depending on what video chipset you're using. The problem is that the retrace occurs for significantly less than one ms in most resolutions, so it's easy to miss it entirely, even with Linux/lowlatency. Besides, it's a huge waste of CPU power, spending lots of time polling. However, RTL allows a periodic thread to do the polling, starting just before the retrace is expected, reducing the wasted CPU time to almost nothing. This thread can then provide the grapics engine with a reliable retrace sync info. In the case of graphics drivers that don't support true pageflipping, but use blits instead, this retrace sync driver can be used to allow the back->VRAM blit to start at the right time, which is required to avoid tearing. //David ..- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `--> http://www.linuxaudiodev.com/maia -' ..- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `--> [EMAIL PROTECTED] -' -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
Tue, 16 Jan 2001 Bart Thissen wrote: > Does any body has experience with the low latency kernel patch and > RTL together? I did try this combination once, and found serious > problems under heavy load, maybe related to bad memory. Did both patches apply correctly? Theoretically, there shouldn't be any conflicts between them, as the RTL patch is effectively adding the capability to intercept interrupts before Linux and to prevent Linux from disabling interrputs on the hardware level, while the lowatency patch keeps the Linux kernel from not rescheduling for extended periods of time. In other words, lowlatency is in the middle of the Linux kernel, while RTL is between Linux and the hardware. Anyway, I've seen posts from a few people successfully using RTL or RTAI and together with the lowlatency patch, so it seems to be doable in real life as well. For various reasons, I've *still* not tried this myself - probably because I only really need it for a project at work; one that has had very low priority lately. //David ..- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `--> http://www.linuxaudiodev.com/maia -' ..- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `--> [EMAIL PROTECTED] -' -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
don't be humbled, I may be wrong. On Tue, Jan 16, 2001 at 10:35:48AM -0700, Nathan Paul Simons wrote: > On Tue, Jan 16, 2001 at 08:38:30AM -0700, [EMAIL PROTECTED] wrote: > > You could have asked me: aside from getting wierd OS failures (which is > > always fun) there is a really interesting area in which "soft" realtime > > applications interact with hard realtime applications: e.g. hard RT > > collects frames, feeds them to a soft RT which does some mixing, and hard > > RT outputs. > > I think that the area in which hard and soft RT cooperate is one of the most > > important research&development areas in OS. > > I stand humbled. My apologies if I seemed overly negative towards the > question of using the low latency patch. It's just that it seems like > applications that require low latency could be deftly handled by using hard > real time, and the low latency patch has a lot of provisos for its use. There > was much discussion on the Linux kernel list about the issues that the low > latency patch raised. While many people said that it Worked For Them(tm), it > looked like the patch would not be compatible with many drivers and perhaps > even platforms (did anyone ever test the patch on anything besides ia32?). > However, if you get the low latency patch and our RTLinux patch to > apply cleanly and work, all the more power to you. I'd be interested to hear > how it works out. -- - Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
On Tue, Jan 16, 2001 at 08:38:30AM -0700, [EMAIL PROTECTED] wrote: > You could have asked me: aside from getting wierd OS failures (which is > always fun) there is a really interesting area in which "soft" realtime > applications interact with hard realtime applications: e.g. hard RT > collects frames, feeds them to a soft RT which does some mixing, and hard > RT outputs. > I think that the area in which hard and soft RT cooperate is one of the most > important research&development areas in OS. I stand humbled. My apologies if I seemed overly negative towards the question of using the low latency patch. It's just that it seems like applications that require low latency could be deftly handled by using hard real time, and the low latency patch has a lot of provisos for its use. There was much discussion on the Linux kernel list about the issues that the low latency patch raised. While many people said that it Worked For Them(tm), it looked like the patch would not be compatible with many drivers and perhaps even platforms (did anyone ever test the patch on anything besides ia32?). However, if you get the low latency patch and our RTLinux patch to apply cleanly and work, all the more power to you. I'd be interested to hear how it works out. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
On Tue, Jan 16, 2001 at 10:10:53AM -0700, John Regehr wrote: > > On Tue, Jan 16, 2001 at 08:17:00AM -0700, John Regehr wrote: > > > The point is that real-time applications have widely varying > > > requirements and, as people have been discussing recently, not everybody > > > wants to stuff their app into the more restricted and difficult > > > enviroment. > > > > I want to point out that (A) RTLinux programming environment is not so > > difficult and > > I agree that it's not that hard, but it does raise the bar somewhat. > The user/kernel boundary is there for a reason, after all: to prevent > buggy applications from corrupting each other or the system, and to make > it possible to reclaim all resources when an app terminates abnormally. > > That said, the real-time signals in RTLinux 3 look really cool, and they > are a nice step towards providing a friendlier programming model. > Thanks. We have a funny message to put out: on the one hand RTL programming requires some skill level but on the other hand, I don't want people to automatically assume you need to be a kernel hacker to write RTL code. > John -- - Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
> On Tue, Jan 16, 2001 at 08:17:00AM -0700, John Regehr wrote: > > The point is that real-time applications have widely varying > > requirements and, as people have been discussing recently, not everybody > > wants to stuff their app into the more restricted and difficult > > enviroment. > > I want to point out that (A) RTLinux programming environment is not so > difficult and I agree that it's not that hard, but it does raise the bar somewhat. The user/kernel boundary is there for a reason, after all: to prevent buggy applications from corrupting each other or the system, and to make it possible to reclaim all resources when an app terminates abnormally. That said, the real-time signals in RTLinux 3 look really cool, and they are a nice step towards providing a friendlier programming model. John -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
On Tue, Jan 16, 2001 at 10:26:36AM +0100, Bart Thissen wrote: > > Does any body has experience with the low latency kernel patch and > RTL together? I did try this combination once, and found serious > problems under heavy load, maybe related to bad memory. I do most of my RTAI hacking (and all of my regular activities) with a 2.4.0 kernel patched with a combo of RTAI, LTT, low-latency, timekeeper, and a few random patches. I've seen no difficulties so far, but if you're interested in attempting to crash it for me, you can find the patches at ftp://ftp.zentropix.com/pub/ds/patches. I tend to upload it only when people ask me, though. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
On Tue, Jan 16, 2001 at 08:17:00AM -0700, John Regehr wrote: > The point is that real-time applications have widely varying > requirements and, as people have been discussing recently, not everybody > wants to stuff their app into the more restricted and difficult > enviroment. I want to point out that (A) RTLinux programming environment is not so difficult and (B) the low latency patches are not so unrestricted. Andrew Morton (who seems to have been the second Linux developer to turn into an entire programming team) has a list of "don't do that"'s to accompany his patch. > One drawback of running soft real-time apps in user space while running > hard real-time apps in RTLinux is that RTLinux will become a source of > latency for regular Linux. In other words, if a RTLinux task has a WCET > of 1ms, then the worst-cast dispatch latency of regular Linux will be > increased by 1ms. Just as the worst-case dispatch latency of SCHED_OTHER processes in Linux gets worse by the worst case compute time of and SCHED_FIFO process. > > John > > > > -- [rtl] --- > To unsubscribe: > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR > echo "unsubscribe rtl " | mail [EMAIL PROTECTED] > --- > For more information on Real-Time Linux see: > http://www.rtlinux.org/rtlinux/ -- - Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
On Tue, Jan 16, 2001 at 03:25:12AM -0700, Nathan Paul Simons wrote: > On Tue, Jan 16, 2001 at 10:26:36AM +0100, Bart Thissen wrote: > > Does any body has experience with the low latency kernel patch and > > RTL together? I did try this combination once, and found serious > > problems under heavy load, maybe related to bad memory. > > Excuse me for asking, but *why* would you want to do this? If you You could have asked me: aside from getting wierd OS failures (which is always fun) there is a really interesting area in which "soft" realtime applications interact with hard realtime applications: e.g. hard RT collects frames, feeds them to a soft RT which does some mixing, and hard RT outputs. I think that the area in which hard and soft RT cooperate is one of the most important research&development areas in OS. > have RTLinux you get hard real-time guarantees, which can be used in the same > way low latency can. As I remember, the low latency patch just sprinkled > schedule() randomly on the kernel source like magic faery dust. Shouldn't > make a damn bit of difference to RTLinux, since it preempts the regular > Linux kernel anytime it wants. Don't know if there are any adverse effects > the other way around, since I haven't tried this, since I don't see the point. > -- [rtl] --- > To unsubscribe: > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR > echo "unsubscribe rtl " | mail [EMAIL PROTECTED] > --- > For more information on Real-Time Linux see: > http://www.rtlinux.org/rtlinux/ -- - Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
> Excuse me for asking, but *why* would you want to do this? If you > have RTLinux you get hard real-time guarantees, which can be used in the same > way low latency can. As I remember, the low latency patch just sprinkled > schedule() randomly on the kernel source like magic faery dust. Shouldn't > make a damn bit of difference to RTLinux, since it preempts the regular > Linux kernel anytime it wants. Don't know if there are any adverse effects > the other way around, since I haven't tried this, since I don't see the point. The point is that real-time applications have widely varying requirements and, as people have been discussing recently, not everybody wants to stuff their app into the more restricted and difficult enviroment. One drawback of running soft real-time apps in user space while running hard real-time apps in RTLinux is that RTLinux will become a source of latency for regular Linux. In other words, if a RTLinux task has a WCET of 1ms, then the worst-cast dispatch latency of regular Linux will be increased by 1ms. John -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
Nathan Paul Simons wrote: > > On Tue, Jan 16, 2001 at 10:26:36AM +0100, Bart Thissen wrote: > > Does any body has experience with the low latency kernel patch and > > RTL together? I did try this combination once, and found serious > > problems under heavy load, maybe related to bad memory. > > Excuse me for asking, but *why* would you want to do this? If you > have RTLinux you get hard real-time guarantees, which can be used in the same > way low latency can. As I remember, the low latency patch just sprinkled > schedule() randomly on the kernel source like magic faery dust. Shouldn't > make a damn bit of difference to RTLinux, since it preempts the regular > Linux kernel anytime it wants. > Of cause it makes no difference to RTLinux, I understand that. > Don't know if there are any adverse effects > the other way around, since I haven't tried this, since I don't see the point. > If the low latency patch 'magic feary dust' works well, a lot of non-hardrealtime tasks can stay in user space, with all it's advantages of programing (libc, libpthread), OS interface (VFS, sockets) and debugging (gdb) being available. In other words: it makes life a lot easier :-) Bart Thissen -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
On Tue, Jan 16, 2001 at 10:26:36AM +0100, Bart Thissen wrote: > Does any body has experience with the low latency kernel patch and > RTL together? I did try this combination once, and found serious > problems under heavy load, maybe related to bad memory. Excuse me for asking, but *why* would you want to do this? If you have RTLinux you get hard real-time guarantees, which can be used in the same way low latency can. As I remember, the low latency patch just sprinkled schedule() randomly on the kernel source like magic faery dust. Shouldn't make a damn bit of difference to RTLinux, since it preempts the regular Linux kernel anytime it wants. Don't know if there are any adverse effects the other way around, since I haven't tried this, since I don't see the point. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
[rtl] RTL + Low Latency patch interference?
Does any body has experience with the low latency kernel patch and RTL together? I did try this combination once, and found serious problems under heavy load, maybe related to bad memory. Bart Thissen, Augan Instruments bv -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
