If I remember correctly I paid a nominal fee for the program. Perhaps CM9000 is abandonware and thus no copyrights have been infringed upon? Also anytime one downloads software one risks a virus. I think I previously confirmed that it works OK on Win7. If I get a hankering for CM 9000, I think I'll just install it on my Windows 7 hard drive. I *could* install Windows 10 on it, but that's more trouble than I want to deal with. My main machine (Linux), which is better hardware but still only an Intel i3, can still run Windows 7 off the net. Unfortunately, I don't think I can help any further, as I'm gravitating away from Windows in favor of Linux. It would be interesting to see if someone else with better hardware had better results. I really got it for Linux, but I recently put Windows 10 on it to play with temporarily. (Dell Optiplex 755, core 2 duo, 4 GB RAM). This is on a very old PC that's probably struggling just to run Windows 10. Well, I haven't been timing the interval precisely, but when I've been paying attention, it seems to happen fairly consistently at around the 4hr:45min mark, or maybe the 4hr:50min mark. If you can install a current supported version thats the ideal situation. I am of course just guessing, but its an educated guess. If the time to failure is pretty much constant then it is likely to be a side-effect of the amount of work that has been done by the software and reducing the processor utilisation won't help. If the time between failures appears random then it may be the kind of timing/chunking issue I described. The high CPU utilisation may be shortening the time between failures. You're running a really good stress test on the software with what you are doing.Īnother option, if you have the hardware, might be to run it on a machine with more processor capacity. The more complex software is, the more likely it is to have these kinds of problems.
These assumptions can be perfectly valid for years even if they do not match the letter of the documentation (or even if they do the documentation can change or be incomplete to start with), but which go away as machines get faster or something deep in the OS changes the handling of data very slightly. Its really easy to build in assumptions about how data that is written arrives at the reader (assuming one blob or various kinds of fragmentation, becoming multiple fragments or different subdivisions of the data). Timing and chunking issues are a particularly awkward area and are very prone to subtle changes over time. This is the problem with old Windows software, or software from any OS. Most of what is in the event log IS gibberish unless you have a passionate interest (wrote the software that produced it) in whatever it is. If its a disk error then you'd see something in the event viewer complaining (with a red icon) about hardware. The reference to read error could be to disk, network or inter-process communication.
0 kommentar(er)
