Dave Engvall wrote: >It is amazing how many DEC users, etc come crawling out of the woodwork. >All of them with great stories about how things used to be. > >With all this architectural experience there ought to be some >strongly held opinions on a processor chip that would do a >good job on real-time applications such as emc and still be >affordable. I really believe that someplace along the path Intel >is going to make the Px unusable for real time. We as a group are >going to need to be able to migrate to some other chip-set. > >Yes, I know I've been smoking the wrong stuff ... or maybe the right >stuff. > >Ideas?? > > Well ...
I agree - mainstream CPUs are heading further from responsiveness and determinism and closer to throughput and "streaming". Realtime interrupt latencies for audio and video (the applications most users interact with which actually need some level of realtime response) are in the several millisecond range, and that can be extended with buffering. Additionally, off-loading the work onto a specific processor (the sound chip or GPU) reduces the CPU load. So the path most hardware vendors take is to make special-purpos chips with large buffers, and don't worry about realtime. Then there's us. We need hard deadlines for interrupt service routines, reasonable determinism as to how long our functions will take to execute, and very fast turnaround time from our hardware helpers (like Mesa, USC, etc.). Even with sub-microsecond interrupt latency, USB would still be useless for many classes of machine, simply because it has 2ms (theoretical) minimum turnaround time for feedback/command data. As for determinism, it's nearly impossible to predict how long a function will take to execute on a modern processor. You can calculate min/max times (assuming you can eliminate paging/swap from the equation, which you can for RT code), and you have to do some statistical combination of the min/max for the various functions you need (in a HAL thread, for example). I believe there are CPU instructions that allow you to lock data in the CPU cache, which should improve both latency and determinism. I don't know how to figure out what parts of data should be held in cache, or what to do if something goes wrong (I don't know if we could tell that anything had been locked in cache in the event of a crash, for instance). To put it plainly, I agree - unless some CPU and/or chipset vendor takes the kind of RT we need seriously, things are going to get bad in the next 5-10 years (if not sooner). Of course, this ignores the role of software in the whole mess. Supposedly, non-RT code can't prevent RT code from running. I've had experiences which appear to support this assertion, and others that seem to contradict it. On the plus side: I've had a machine lock up badly enough that it wouldn't respond to pings, keyboard lights wouldn't toggle, etc. The HAL code kept running quite nicely though, in fact ending up with much more consistent timing with the kernel crashed than it had with the kernel alive (as verified by an external scope). On the minus side: I found on one machine that going from ext3 to ext2 eliminated a latency spike that occured about every 5 seconds. (Actually, I guess both examples are on the minus side regarding non-RT code affecting RT latency, since both cases showed an improvement in latency numbers once non-RT (but still kernel) code was stopped or disabled (or crashed)). I have had delusions about designing a PC-style motherboard with RT/latency as the priorities rather than benchmarks and video throughput, but that's a big (BIG) task. Points to ponder anyway. - Steve ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
