Timeline for What's the most absurd myth about programming issues?
Current License: CC BY-SA 2.5
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 22, 2010 at 17:30 | comment | added | David Thornley | I was raised thinking that soft real-time meant fast enough by guarantee, and hard real-time meant deterministic time slices. By this definition, the first app I worked on, a reporting system for railroads based on punch cards, was soft real-time because all processing could be done before the train got anywhere else. That doesn't mean it was fast by modern standards. | |
| Sep 19, 2010 at 2:32 | comment | added | configurator | @Richard: Indeed, iTunes always takes a few minutes before playing anything. Oh, that's not what you meant? | |
| Sep 11, 2010 at 8:43 | comment | added | Evan Plaice | real time is only necessary in systems that require extremely low latency feedback. Ex, motion controls for hydraulic systems and/or mechanical systems, industrial automation, etc. Most of which will be gained using custom hardware, PLC, or industrial specific hardware. The applications of real-time in a PC computing environment are extremely few and far between (which is probably why nobody really understands what it means) and usually require a platform with multiple cores/CPUs to support simultaneous multiprocessing. | |
| Sep 10, 2010 at 22:02 | comment | added | Rusty | @JohnFx Well put. Concepts need Context. | |
| Sep 10, 2010 at 14:30 | comment | added | JohnFx | This is probably just one of those cases where a badly named concept contributes to confusion. | |
| Sep 10, 2010 at 0:27 | history | made wiki | Post Made Community Wiki | ||
| Sep 9, 2010 at 19:02 | comment | added | Rusty | @spudd86 Uncertainty is required by physics so it will exist and must be accounted for. It is in "hard" real-time systems designed for reliability..like fly-by-wire..where failure impacts life safety. Everything is accounted for cache, memory,etc. in these systems. But this has little to do with my post. My post only concerns the misconception that saying something is "real-time" somehow means that it is fast...it does not. It needs to be quantified. Real-time on W7? Sure. If 4ms of jitter, random >50ms skips meet your spec..then your real-time. Before you say it: real-time doesn't mean safe. | |
| Sep 9, 2010 at 17:53 | comment | added | Spudd86 | Well on real systems fully deterministic execution times are nearly impossible (if it has a CPU cache you're pretty much hosed for totally deterministic, and desktop class CPU's worst case for stuff that's IN MEMORY is an order of magnitude longer than if it's in cache, since we're talking real time I'll assume swap isn't an issue and not even bring up the worst case for that...) | |
| Sep 9, 2010 at 17:45 | comment | added | Rusty | @burnt_hand The trick is you must specify "as you require it" in units a computer can understand...if you don't then "whatever was happening as you require it" is at whatever rate it happens to be. And that would happen to be unknown. In the context of computers and software "real-time" needs a value. | |
| Sep 9, 2010 at 16:50 | comment | added | Richard Gadsden | A good example of a real-time program: iTunes. When you're playing music, the length of time it takes to play a song is deterministic. | |
| Sep 9, 2010 at 16:18 | comment | added | Dan | I always thought real-time meant whatever was happening was happening as you require it, not a reference to time taken. | |
| Sep 9, 2010 at 13:40 | comment | added | brian chandley | real-time=near-time | |
| Sep 9, 2010 at 12:51 | history | answered | Rusty | CC BY-SA 2.5 |