DF Client not stable with Windows Multi-CPU systems
I've been running the DF client for some months now and I'm consistently getting the same "file write" or "faulty-RAM" messages on my Multi-CPU Windows-Intel Servers. It's always the same; over time, if I'm running multiple instances of the client on a multi-CPU system, I will get these error messages on all but one instance of the client. For example, if I'm running 8 instances of the client on a 8-way system, over time I will end up with only 1 instance still running.
I am also using single CPU servers and clients, and I've noticed that I NEVER, EVER have a problem with DF on these systems.
I have 100% confidence in the Memory, I use in my systems, since I've used these systems to test much more memory and CPU intensive application than DF over long durations and have not seen any issues.
Can you please investigate this issue with multi-CPUs? As you can probably guess from my output thus far, I'm running a sizable farm and it's getting tiresome to have to maintain these systems. Thus far with the latest protein, my hourly production has see-sawed from as low as 190K to 500K. Currently, I'm on the lower end of this range not because I removed any clients from DF, but because the DF application has not been stable over time, and I do not have the time to restart all the instances that have "failed".
On a separate topic, are you ever going to optimize this client for Intel based 64-bit CPUs? I've ran this on a 64-way server and it's very slow, even though the entire application can fit in the L2 cache of each CPU.
Thanks.
deficiencies in the client -- NOT !!!
Gentlemen,
I did NOT see anyone complaining that indicated they were using Linux or non-windows operationg systems. This is a windows problem, NOT an application problem! True, the application may be stretching windows limits, but so be it.
Quote:
I don't mind too awfully much having to install a client for each CPU in it's own folder, but that's as far as I want to go. Having to customize batch files, and make extra TEMP folders is too much.
Set it up once in a generic manner and its a piece of cake... "set TMP=..\tmp" works for me in windows....
Quote:
Ultimately, the client should figure out how many CPUs are in the box , and start up enough processes to run one protein for each CPU, whether it's a 'real' CPU, or a virtual HT CPU. I realize that only XP recognizes the HT virtual CPUs for what they are, but W2K recognizes them as CPUs, just doesn't know they are HT.
Now, this is NOT the way to go if you are trying to get an application to run on multiple platforms.... Applications should NOT dig into the platform to make decisions about how to run unless the application is running the environment. Here the object of the application is to perform work.
Ask Microsoft to fix its operating system... (I know... lost cause!)
My two cents worth... Ned
:cool: