Don Stanley said, in part: > I was grudgingly coming to the same conclusion. I did some comparisons > today. I could not believe the fastest computers in the shop with minimum > graphics (the AMD Atahlon 64 4000+ we have trying to fix) only performs > slightly better than a Pentium IV 400MHZ running EMC2. > The trouble is, Don, despite various O/S-developers' attempts to hide the hardware, it simply is not true that, except for speed, all computers are kind of the same.
For nearly a decade now, PC makers and their component suppliers have seen good profit margins in making two classes of PCs---media centers (which optimize for high throughput of audio and video with complex media-stream encoding/decoding requirements---think mpeg2, mpeg4, H.264,...) and game machines (which optimize for complex, detailed and fast changing computer-generated scenes including textures and the whole nine yards of graphics tricks---think DX8, DX9, DX10,...). In this same decade, electrical power consumption in the home and office has become a hot-button issue. The user's perception of the speed and responsiveness of these machines has almost nothing to do with the qualities we need in real-time control. The qualities we need for real-time control have been designed out of these machines almost inadvertently as other goals are being pursued with new, "improved" multi-core, multi-threading CPUs with their new, "improved" North and South Bridges, new, "improved" power management, and all the other hardware paraphernalia. Old, "un-improved" Pentiums end up looking very good when your foremost goal is consistent, low latency. When you look at the numbers of PCs and shrink-wrapped software packages that are shipped to consumers you realize that in comparison we constitute a market potential closely approximating zero. We don't generate any requirements worth considering in PC product planning. We just get to work with the result. Have you seen the Far Side cartoon of a frog with its tongue stuck to a jet plane that was flying over its lily pad? That's a metaphor for our situation. One might think that there's an opportunity here for an entrepreneur to build and sell EMC2-customized computers, but such a person would be a small-volume buyer at the mercy of fickle suppliers, and I suspect folks in the CNC marketplace like Jon Elson, Steve Stallings, and others can also recite chapter-and-verse about the burden of after-sales support for something this technical. The only way I could imagine making money is to build custom controllers that are sold as part of a complete machine-tool system with a high purchase price and high annual maintenance fees. Oh, wait, isn't that what .... I feel your pain and I know that trying to explain why you have it doesn't make it go away. A lot of us on this mail list and its companion developers list have been hoping/struggling/arguing to find a path forward that minimizes the pain. There's been little enough joy so far. On the positive side, once you get a platform that does function well with Linux/RTAI, then you have EMC2 and all that this implies. Regards, Kent PS - sorry, all, for my recent faux pas with my email subject lines. When it's been too long since my last cup of coffee, I tend to not to check closely enough before clicking "send". ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
