Messages in this thread | | | Date | Sun, 28 Jan 2001 22:02:08 -0700 | From | yodaiken@fsmlabs ... | Subject | Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0 |
| |
On Sun, Jan 28, 2001 at 06:07:04AM -0800, Bill Huey wrote: > > On Sun, Jan 28, 2001 at 06:14:28AM -0700, yodaiken@fsmlabs.com wrote: > > > Yes, I most emphatically do disagree with Victor! IRIX is used for > > > mission-critical audio applications - recording as well playback - and > > And it has bloat, it's famously buggy, it is impossible to maintain, ... > > However, that doesn't fault its concepts and its original goals. This > kind stuff is often more of an implementation and bad abstraction issue than > about faulty design and end goals.
That's the core of the disagreement. I think SGI had some really good engineers who have worked very hard - but that hard work and good programming can never compensate for bad design. I think Linux works so well because it's been designed well -- and good design often means refusing to go down a path that is known to seemingly invariably lead to failure. HP-UX, IRIX, Masscomp ... -- all these guys have tried this "concept" and all have had some sucess, but at a very high price.
> > > > used. I will be very happy when Linux is as good in all these areas, > > > and I'm working hard to achieve this goal with negligible impact on the > > > current Linux "sweet-spot" applications such as web serving. > > As stated previously: I think this is a proven improbability and I have > > not seen any code or designs from you to show otherwise. > > Andrew Morton's patch uses < 10 rescheduling points (maybe less from memory) > and in controlled, focused and logical places. It's certainly not a unmaintainable > mammoth unlike previous attempts, since Riel (many thanks) has massively > cleaned up the VM layer by using more reasonable algorithms, etc... >
Andrews' patch has grown, but sure, I think he is doing good work.
> > I suggest that you get your hearing checked. I'm fully in favor of sensible > > low latency Linux. I believe however that low latency in Linux will > > A. be "soft realtime", close to deadline most of the time. > > Which is very good and maintainable with Andrew's patches. > > > B. millisecond level on present hardware > > Also very good an useable for many applications short of writting dedicated > code on specialized DSP cards. > > > C. Best implemented by careful algorithm design instead of > > "stuff the kernel with resched points" and hope for the best. > > Algorithms ? which ones ? VM layer, scheduler ? It seems there's enough > there in the Linux kernel to start doing interesting stuff, assuming that > there's a large enough media crowd willing to do the userspace programming. > > > > for low-latency tasks. RTLinux is not Linux, it is a separate > > > environment with a separate, limited set of APIs. You can't run XMMS, > > > or any other existing Linux audio app in RTLinux. I want a low-latency > > > Linux, not just another RTOS living parasitically alongside Linux. > > > Nice marketing line, but it is not working code. > > Mean what ? How does that response answer his criticism ? >
RTLinux is not intended to be another Linux - one Linux is enough (and one IRIX is too many!). What RTLinux does is, essentially, add a special realtime process to Linux and let applications in this "process" be written as threads and signal handlers. The environment is specifically made to be "restrictive" and programmers are encouraged to put non-realtime components in Linux and only put timing critical stuff in the RT process. So complaining that the RTLinux environment is not the Linux environment is rather silly and akin to a complain that you can't call shell scripts from driver code. Different environments serve different purposes. The engineering claim behind RTLinux is that while many attempts to integrate hard realtime into general purpose OS's have produced large buggy, slow, and compromised OS's, the RTLinux model provides a simple software design that offers reliable hard realtime without screwing up the internals of the general purpose OS. In fact, I argue that it's a mistake to integrate hard realtime and non-realtime code in applications as well. So I think that the argument "we should have hard realtime in an integrated environment" is like arguing "we should have fast cornering, and instant acceleration in a moving van". If you don't like my sports car because it does not come with air brakes and a trailer, show me how it's possible to accomplish both design goals: but don't simply "marketize" about how inferior the sports car is because it is missing moving van features.
> bill
-- --------------------------------------------------------- Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |