| |||||||||||||
|
| |||||||||||||
Enterprise realtime and cooperative developmentEnterprise realtime and cooperative developmentPosted Dec 5, 2007 21:14 UTC (Wed) by troyhebe (subscriber, #22084)Parent article: Enterprise realtime and cooperative development
Why do people always assume real-time = "lightning-fast response" and "Losing too many milliseconds in the execution of an order can cost real money.". real-time simply means deterministic worst case time. A real-time system could have a worst case time of 3 hours and still be real time. Real-time does not necessary mean fast.
(Log in to post comments)
Enterprise realtime and cooperative development Posted Dec 5, 2007 21:41 UTC (Wed) by nix (subscriber, #2304) [Link] Yeah, but a system with a 3 hour hard realtime bound can in practice be implemented with pencil and paper in many cases: virtually any normal OS could handle bounds like that (OK, so it couldn't *guarantee*, but it could push the probability down arbitrarily far, farther down than, say, the likelihood of hardware failure in that timespan). Hell, I've implemented hard-realtime hardware control systems with 3s bounds using mlock()ed processes on ordinary Unix platforms. (Your only problem then is priority inversion, and the easiest solution to that is to dictate what is running on the box, which is generally 'not a lot' for such systems, and to take care with the locking design of one's own program, if it includes processes running at different priorities.) The only time realtime stuff is interesting for the OS is when priority inversion really is an issue or when the realtime bounds are quite tight.
Enterprise realtime and cooperative development Posted Dec 6, 2007 3:27 UTC (Thu) by kingdon (subscriber, #4526) [Link] Well, deterministic worst case is the traditional definition, but as soon as you have memory caches, fancy CPUs (so you can't just count the cycles for each instruction and add them up), etc, life is rather fuzzier and even knowing what the worst case is can be hard. One of the things which makes the marketing (and the engineering) of this so complicated is that real time has a fairly wide variety of definitions (likewise for "embedded" and some other terms).
Enterprise realtime and cooperative development Posted Dec 6, 2007 4:47 UTC (Thu) by sobdk (guest, #38278) [Link] Well, because while it is true that real time means "deterministic worst case time" it is also true that real time customers want that worst case time to be as small as possible. This may mean that a RTOS may have a slower response time than a non-RTOS, but it also means that you have a guarantee you won't loose "too many milliseconds in the execution of an order" which you simply can't get from a non-RTOS.
realtime vs fast Posted Dec 7, 2007 0:52 UTC (Fri) by giraffedata (subscriber, #1954) [Link] it is also true that real time customers want that worst case time to be as small as possible I don't think that's particularly true. While it's true that computer users in general want worst case time to be as small as possible, real time people are probably less demanding than non-RT people. Say you're running an automobile's cruise control. You have to make adjustments every 100 milliseconds. It's essential that your worst case response time be less than 100 milliseconds, but every bit faster than that is just a waste of money. But in a web server, every bit faster you can serve a page is worth something.
Enterprise realtime and cooperative development Posted Dec 6, 2007 19:05 UTC (Thu) by adesharatushar@gmail.com (guest, #49449) [Link] As per my little understanding about RealTimeOs, it is more about starting the process as early as possible rather then speed of the process, isn't that the case?
realtime vs fast Posted Dec 7, 2007 1:04 UTC (Fri) by giraffedata (subscriber, #1954) [Link] As per my little understanding about RealTimeOs, it is more about starting the process as early as possible rather then speed of the process, isn't that the case? Well, almost. It's about finishing the process as early as possible. And that's true only in the big picture. In an individual system, it's not ending it as early as possible, but just ending it before some externally imposed (i.e. real time) deadline. While the OS doesn't completely control when the process finishes, it has plenty of influence beyond just controlling when it starts.
|
|
||||||||||||