i think it works well on gaming.
i've heard both that it may make things worse in gaming and better so not sure yet about it. with an ogg playing and a software audio mixer it still seemed very responsive so at least for now i tend to think it improves things, or, leaves them the same compared to the previous "low latency desktop" option.
ps. now why does it spam the log with gibberish..
Advertisement
Page 1 of 1
real time patches
#2
Posted 24 October 2006 - 01:35 AM
I've yet to try the RT patches on my system. For the most part real-time computing is designed for responding to external events within a certain amount of time. These can be at static intervals or dynamic (in the case of interrupts). I'm not seeing any real advantage to gaming; I mean, these patches were mainly made for embedded applications, not 3D first person shooters. If you do run RT on a gaming system, you can almost expect to see degradation in other system services, hopefully none that are critical. Give it a shot though, let us know how it turns out.
#3
Posted 24 October 2006 - 02:11 AM
i read some of that theory and was a bit surprised that in menuconfig it's described another way. unless i miss something, it's described as the preemptive scheduler but taking that idea to the extreme. i guess it's the same in other words, or how it works technically in the bottom line.
in preempt-desktop:
in RT:
after some regular usage i don't see major differences (other than an incident of gibberish log spam). maybe there's isn't much to notice going from preempt_desktop to rt in regular use. (after going from 'server' to 'preemptive desktop' I believe it felt obviously more smooth in multitasking)
in preempt-desktop:
Quote
This option reduces the latency of the kernel by making all kernel code that is not executing in a critical section preemptible.
(..)
(According to profiles, when this mode is selected then even during kernel-intense workloads the system is in an immediately preemptible state more than 50% of the time.)
(..)
(According to profiles, when this mode is selected then even during kernel-intense workloads the system is in an immediately preemptible state more than 50% of the time.)
in RT:
Quote
This option further reduces the scheduling latency kernel by replacing almost every spinlock used by the kernel with preemptible mutexes and thus making all but the most critical kernel code involuntarily preemptible.
(..)
(According to profiles, when this mode is selected then even during kernel-intense workloads the system is in an immediately preemptible state more than 95% of the time.)
(..)
(According to profiles, when this mode is selected then even during kernel-intense workloads the system is in an immediately preemptible state more than 95% of the time.)
after some regular usage i don't see major differences (other than an incident of gibberish log spam). maybe there's isn't much to notice going from preempt_desktop to rt in regular use. (after going from 'server' to 'preemptive desktop' I believe it felt obviously more smooth in multitasking)
#4
Posted 24 December 2006 - 04:51 PM
been running for some days a 2.6.19 version of it. urt plays fine with it, the system looks fine but there's a little problem. if for example more than 4 firefox tabs try to load pages, it gives sporadic freezes in mouse movement and audio playing. perhaps the 'low latency desktop' option of the main kernel is the way to go. it doesn't do those.
Page 1 of 1