Real-time operating systems
Author
I'm posting this here rather than the game programming forum as I consider it more generally technical...
Would a real-time operating system, like real-time linux, provide any benefit for an on-line game, either server or client side?
This is meant to be purely theoretical.
I have to admit, I much prefer a real time operating system to a turn based one, it's just so much more productive and works alot more smoothly for me.
Real-time operating systems are designed to be really fast and run without a lot of resources, but usually at the cost of other things such as a lot of memory or generality. I imagine it would be difficult to implement a full on-line game on a real-time OS because you wouldn't have all the services of a regular OS.
Author
Quote:Original post by Zipster
Real-time operating systems are designed to be really fast and run without a lot of resources, but usually at the cost of other things such as a lot of memory or generality. I imagine it would be difficult to implement a full on-line game on a real-time OS because you wouldn't have all the services of a regular OS.
If the team actually designed/modified a real-time system specifically for the game I would think you could incorporate the services you need, while creating a platform for future titles.
Author
Could you implement something client-side that allowed the game, when run, to reboot into its custom OS? Obviously not easy, unpractical, and probably unsafe. But would there be benefits to be had, at least for real-time on-line games?
No, none.
RTOSes are useful when you need things done at exact times, and are willing to sacrifice speed and power in order to be able to do so. If you needed to turn a light on, and then turn it off exactly 0.0032813 seconds later, an RTOS would be great. If you just wanted to keep your framerate above 60, an RTOS would be the absolute worst choice possible, since in order to satisfy time guarantees you'd have to allocate more time to each module than it probably actually would need, and would end up spending a lot of time blocking.
RTOSes are useful when you need things done at exact times, and are willing to sacrifice speed and power in order to be able to do so. If you needed to turn a light on, and then turn it off exactly 0.0032813 seconds later, an RTOS would be great. If you just wanted to keep your framerate above 60, an RTOS would be the absolute worst choice possible, since in order to satisfy time guarantees you'd have to allocate more time to each module than it probably actually would need, and would end up spending a lot of time blocking.
No, there is no benefit to RTOS outside specialized areas, mostly areas where failure to meet the timing deadlines will cause significant trouble, like death. Think nuclear power plant, airplane "autopilot", or spacecraft.
Perfect, ideal real-time scheduling is NP-complete. So every RTOS scheduler in existance is some compromise based on the goals of the developer. Mostly there is a huge expense in throughput.
So if your game runs in a real-time OS, either client or server, expect the wasted CPU time to be very high. So your performance would suck, essentially.
And also, there are practically NO standard drivers for RTOS. Any flavor of real-time linux comes close, but don't expect much support for non-essential things like graphics cards when in RT mode.
Perfect, ideal real-time scheduling is NP-complete. So every RTOS scheduler in existance is some compromise based on the goals of the developer. Mostly there is a huge expense in throughput.
So if your game runs in a real-time OS, either client or server, expect the wasted CPU time to be very high. So your performance would suck, essentially.
And also, there are practically NO standard drivers for RTOS. Any flavor of real-time linux comes close, but don't expect much support for non-essential things like graphics cards when in RT mode.
Quote:Original post by Ned_K
If the team actually designed/modified a real-time system specifically for the game I would think you could incorporate the services you need, while creating a platform for future titles.
They have that. They're called consoles [grin] You wouldn't consider them "real-time" but they're basically platforms and software designed exclusively for games and other (limited) multimedia.
Games have soft realtime requirements ... we aren't talking about controlling a laser used for eye surgery here (which would require a real time operating system) ... and for the most part, current OS'es suffice. And as it was mentioned, "real time" does not imply more performance ... for all practical purposes it requires more system resources than normal.
One thing games do benefit from is the use of realtime (rather, soft realtime) garbage collectors ... we can have automatic memory management and still reason about its behavior. What doesn't really help us is to have garbage collects that cause visible drops in FPS (or anything else that causes visible drops in FPS for that matter).
One thing games do benefit from is the use of realtime (rather, soft realtime) garbage collectors ... we can have automatic memory management and still reason about its behavior. What doesn't really help us is to have garbage collects that cause visible drops in FPS (or anything else that causes visible drops in FPS for that matter).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
