Re: [rtl] OpenGL?
David Olofson schrieb: > > Correctly, but we were discusing about visualization using OpenGL :-) > > Yes, but even some games and other heavy multimedia applications stream from > disk and/or various forms of dynamic loading of world data. One reason to do > that is to reduce loading times, so one can't just dismiss this with "but you > can use more RAM". How about a 1 Gig RAM-Disk? :-) > > [ 10 ms pause in rt-app ] > The problem is probably that you're choking the rest of the system until you > run into a dead end and *have* to sleep for some reason - and at that time, > you're out for a good while... Oh, forgotten to tell: "a 10 ms pause in rt-app which is in SCHED_RR mode". means: this task will be allways scheduled next, if it desires the CPU - in this case: when the 10ms sleep is over. You may call it cooperative multitasking :-) > QoS in it's simplest form basically means that you can have a certain amount of > things done within a certain amount of time. Isn't that exactly the definition for hard real time? :-) IMHO QoS is this: The operating system guarantees the application some kinds of services. This might be a minimum network or harddisk bandwidth, or simply a minimum amount of task slots within a certain time - "CPU bandwidth", as linux/rt provides. Ok, this basicaly sound similar to your definition, but if the provided service is usefull for the application, that is something completly different! Example: within a 40 ms period, 30 ms are fixed to the 3D application. So if your 3D-Card is basicaly strong enough the generate 25 fps with 75% of the CPU computing power, then your application will run smooth enough for a Men Machine Interface. If you need a scene redraw rate bounded to the refresh rate of the screen (because some machinery has to bother with it) then this doesn't work, of course ... At least, you are right: to perform QoS, you need some kind of real time operating system, but for an MMI, it is IMHO sufficient to have 10-20 ms latency (depending on the application). But: For many people on this list, 10 ms might sounds like eternity :-) So IMHO, the "low latency patch enhanced soft real time capabilities of a linux operating system" (sounds like a marketing term) should be sufficient for QoS. Bernhard -- [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/
Linux/RT availability, was: Re: [rtl] OpenGL?
Sven Garbade schrieb: > Don´t know if you mean this: > > http://www.cs.cmu.edu/~rajkumar/linux-rk.html#Download Exactly, but this is the stinky old version of Linux/RT formerly called Linux/RK. At least, half of the problem is solved. The correct path to version 1.1A is ftp://www.timesys.com/pub/linuxrt/ Version 1.2.1 might life in ftp://www.timesys.com/protected/ I'd like to try if version 1.2.1 works better with Athlon: version 1.1A only allowed a 10 ms resolution and a minimum period of 100ms, afair - too bad for gaming :-) Seems like Linux/RT doesn't recognice the Athlons APIC and makes a fallback to the legacy timer ... Bernhard -- [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] OpenGL?
Thu, 18 Jan 2001 Bernhard Kuhn wrote: > David Olofson schrieb: > > > > > Trust me: as long as the application itself doesn't do disk > > > accesses (including swapping due to high memory usage), > > > it's the only application running on the system at all and > > > therefore running absolutly smoothly. > > > > Well, see above; that's no good for hard disk recorders and direct-from-disk > > samplers! :-) > > Correctly, but we were discusing about visualization using OpenGL :-) Yes, but even some games and other heavy multimedia applications stream from disk and/or various forms of dynamic loading of world data. One reason to do that is to reduce loading times, so one can't just dismiss this with "but you can use more RAM". > [ retrace sync ] > > two years ago, i did a simple RT-Linux program, that measures > the time between two retrace signals and then sets itself asleep > until 20 microseconds before the next retrace signal will apear. > then it does the busy wait and performs a software interrupt. > Worked rather well and went into the GGI-coda, afair, > but modern GFX-card should generate an interrupt on vblank!? On the contrary, the trend seems to be that modern cards do *not* generate retrace interrupts like most of the old cards did. The reason seems to be that they provide a better alternative; double or triple buffering with GPU commands for flipping and sync. However, that doesn't help if no drivers make use of it... This reminds all too much of a discussion on the kernel list, regarding WinModems and Linmodems (ie software modems; line interfaces without DSP power). There has also been similar discussions related to other hardware. The story is basically that RTlinux or similar *could* be made part of the mainstream kernel, but that would only encourage hardware developers to release more crap hardware, broken by design. The RT extension would allow drivers to "fix" the problems, making it appear to end users as they got nice hardware. The problem with that is that it would eventually result in Linux being loaded with RT drivers fighting a latency war, and that in turn would render Linux useless for hard RT work - back at square one! So, if a retrace sync solution is going anywhere near mainstream releases of Linux or drivers, I think the solution has to work without RTL or RTAI. The hard part is that in order to be of much use, it still has to be very reliable... No problem if the rendernig code and the GLX drivers run SCHED_FIFO, and we have true hardware double or triple buffering, but with "blit flips", it's getting complicated. The question is basically "Try to fix it, or give up on all drivers without real pageflipping support?" I think one could hack Utah-GLX to do triple buffering with the current back->front blit method, using two back buffers and a performance counter check + occasional retrace sync somewhere in the low level driver, but I'm not sure it's worth the effort. (Interesting hack though, so I might have a go at it either way. :-) > [ Watchdog mechanism ] > > > Will get back to it some time. It will very likely gain priority as I get > > increasingly tired of looking at the fsck progress bar! ;-) > > Tip: Use ReiserFS - saves a lot of time and nerves ... Yeah, planned to use it on the new 933, but never got around to it. > I am using it for a year for now ... no loss of data even with > hundreds of crashes because of unstable drivers and/or > while developing on (rt-)kernel level. Seems like a good idea when using unstable stuff! :-) (And it seems I pretty much have to, as the stable versions of most of the stuff I depend on is basically useless.) > [ 10 ms pause in rt-app ] > > > Yeah, you give the kernel and all kinds of other things extra chanses to steal > > the CPU from you and keep it for quite a bit longer than the desired 10 ms... > > Yes, but even then, things appear to be much smoother ... The problem is probably that you're choking the rest of the system until you run into a dead end and *have* to sleep for some reason - and at that time, you're out for a good while... If you're not running SCHED_FIFO, it could just be the normal operation of the Linux scheduler, as I understand it. If you never sleep, you'll eventually find yourself preempted by a thread that has the same or even ower priority than you, and at that time, it'll take a while before the scheduler lets you in again. (IIRC, the scheduler is using a kind of dynamic priority offsets to implement the time sharing without explicitly "pulse width modulating" the threads, and that's not what you want for real time work.) > [ latency patch ] > > > Could potentially fix most of the problems, but we may still be facing problems > > caused by the fact that X is not a real time application. > > You are probably right. At least. IMHO, these kind of application > don't need to be done in "Real Time". Here, "Quality of Service" > is needed. I don't see QoS as very different from RT.
[rtl] network programming
hello this may be a simple question, but I cannot get any information on the net so there it goes: I have this program that sends data over a LAN. At this point I'm using UDP but in the future I may have to use TCP/IP. The program works well in the user-space, but I want it to run within rtl. I have included the rtl.h header in my program and try to compile it with the make file rtl.mk. But it comes up with hundreds of warnings, most of them redefinition problems. The header files included are: sys/socket.h netinet/in/h arpa/inet.h netdb.h the redifinition are found in: usr/src/rtlinux-2.3/linux/include/linux/ Do I have to use rtlinux header files? Is there any example I could look at? thanks in advance RAul Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie -- [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] OpenGL?
Bernhard Kuhn wrote: >> Could potentially fix most of the problems, but we may still be facing problems > > caused by the fact that X is not a real time application. > > You are probably right. At least. IMHO, these kind of application > don't need to be done in "Real Time". Here, "Quality of Service" > is needed. The best solution for smooth 3D rendering > is certainly the Linux resource kernel from Raj (maybe mixed > with the low-latency patch), but Linux/RT doesn't > seem to be open any more: Today, i tried downloading > then new version 1.2.1, but the ftp-server is password > proteced :-( You only can buy a CD for $49. Does anybody > know more about this problem? Don´t know if you mean this: http://www.cs.cmu.edu/~rajkumar/linux-rk.html#Download There you don´t need a password nor to by a CD. There some notes pointed out that this is a preliminary release which is not been released publicly yet becuase of some missing implementations. But maybe this is a heavily outdated release. Bye, Sven -- [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/
