Folding Forum

Tmoble,
Using your method worked for me. The only exception was that after deleting those files and running with -configonly, the program went through settings and again closed. Removing the -configonly flag solved the issue. So far so good on 2 machines. Thanx again.

I'll discuss this with our client dev team.

dark41 wrote:No surprise that Linux would run F@H better since a basic OS like W2K runs it slightly better than XP and Vista with identical hardware. All the more reason for not stopping support for W2K I'd think. However I still like having the option to run other programs and games on our extra machines, so Linux will never be found on any of our personal systems.

Sorry, but it's not the OS that determines the folding speed. The CPU client runs at exactly the same speed on Windows and Linux.

With the SMP client, the two operating systems use very different software packages to make SMP possible. And since SMP software was originally designed for the Linux side, it has a few development revisions on the Windows side, and so it is a bit more optimized. Windows will catch up eventually.

7im wrote:
Sorry, but it's not the OS that determines the folding speed. The CPU client runs at exactly the same speed on Windows and Linux.

If my understanding of how the SMP version works is correct, your statement is not exactly true. Please feel free to correct me if I'm wrong:

It is my understanding that the SMP version uses all available CPU clocks, or any clocks not used by other processes, services, apps, etc.. While a CPU clock may perform at the same rate on every OS, more available CPU clocks will obviously finish faster than less CPU clocks will.

An OS that has more processes and services running will have less CPU clocks available for folding, and thus finish the same WU slower. So the OS actually does influence the speed of the WU completion process.

A bare bones W2K installation has less running in the backround than XP and will finish faster. At least that's been my experience with identical hardware and the various OS's. I could understand slight variances for a couple systems, but over a dozen systems I believe the results have proven to be valid.

In fact our (2) E6420 systems overclocked to 3.6GHz and only folding 24/7 will finish WUs faster than our E8400 systems overclocked to 3.6GHz while we use them to check emails and surfing online. The E8400 should be faster, but obviously there are less clocks available for folding while we're doing other things.

Vista Ultimate has so much running in the backround that it slows my WUs considerably. I can see each step jump from 12 minutes to up to 18 minutes depending upon what the OS is doing on it's own (just watching the CPU usage in task manager). Bare bones XP usually takes 11 minutes for each step. Bare bones W2K Pro usually takes 10 minutes for each step.

If I'm wrong about the reason for this variance I'd sure appreciate an explanation for it. But no matter the reason, I've consistently completed WU's faster on W2K than either XP or Vista with the same hardware.

VijayPande wrote:I'll discuss this with our client dev team.

Thank you VijayPande.



For what it's worth, I've found a slightly simpler way to get 5.91 working again on both XP and W2K.

1) uninstall all F@H clients, or start with a clean system

2) install FAH6.22beta2-win32-SMP-mpich.exe

3) rename [email protected] (in program files/Folding@Home Windows SMP Client V1.01)

4) download and copy fah-SMP-591.exe into folder (program files/Folding@Home Windows SMP Client V1.01)

5) run install.bat

6) start program (fah-SMP-591.exe) (can copy shortcut to desktop and drag to start menu if desired at this time)

That has saved me from downloading and deleting work units and has worked on 6 machines so far without a problem on both XP and W2K.

You're both right, but it depends on which factor is more significant.

If you evaluate how busy a completely idle system is, you'll see that the background services generally take less than 1% of the processor time. This number will be different on different OSs and can always be reduced by eliminating unnecessary services. (The first think I generally do with a new system is to suspend the indexing service. If I need to search for something, I'm willing to wait while it happens rather than repeatedly update an index that I rarely use.) Anyway, whatever the numbers actually are, they do subtract from the time that the OS has to work on FAH.

The MPI code used by the Windows SMP client is certainly problematic in many ways. As near as I can guess without seeing the actual code, it's pretty obvious that the four FahCore_a1 tasks do a really huge amount of inter-task communication. Since the MPI code supports this I/O and it is probably executed at every step, doing anything like that 2.5 million times (or 80 M) per WU is going to have a big influence on the actual throughput. Since this I/O is not performed by the OS, it happens in user code, it is difficult to know how much this slows down SMP, but any actual inefficiencies are magnified greatly.

The uniprocessor code doesn't have this problem, of course, so if Win2k allows it to run at 99.7% efficiency and XP runs at 99.5% and Vista runs at 99.0% the differences are small enough that it's difficult to measure. (Arbitrary numbers -- feel free to make your own estimates.)

I will admit that when I said the clients run at exactly the same speed for the CPU client, I meant the difference has historically been too small to measure (i.e. linux vs. Win2K and WinXP equals no notable difference in speed) (figurative, not literal). And if you can't measure it, it doesn't exist.

But just as Windows bloat has grown, so has the bloat in Linux, though not nearly as fast. I'm not so sure that Vista compared to the latest Kubuntu isn't that different from Win2K vs. the early versions of Red Hat. It's relative. But I will also admit that I haven't directly compared Win2K to XP to Vista on the CPU client, but then that wasn't the original question either.

Anyone is more than welcome to do testing and try to show an exact performance difference, though you would need to use very exacting and methodical processes to get accurate and valid measurements. Though the .25% difference (guess) in the CPU client isn't nearly as interesting as in the current SMP clients, which is easily hitting double digit percentages.

Please also note that the performance bottleneck in the CPU client is in the SSE processing, not in the number of free CPU cycles. So even if the OS steals a few cycles to run background services in Windows, unless those services also need SSE, the impact on performance is even less than you might guess.

OK, i understood most of that.

The differences I've seen are measurable, although not earth shattering. And of course each WU is different so that makes it hard to compare apples to apples.

I just hope the developers rethink support for W2K. IMO it's still the most stable OS MS has ever provided. It's lean and mean. But mostly, it would be a shame to let these systems sit idle when they could be contributing to the cause. Although my systems have pretty recent hardware, I suspect there are a lot of older systems that people have hung onto when updating to new systems which have been used exclusively for folding. I recommend to all my customers to install and run F@H on both their new systems and their old systems because I think the cause is worthwhile. Seems to me we should be looking at ways to increase folders, rather than exclude them. I still fold on my older Pent D 3.0 @ 90% with 2003 Server. The WUs take a couple days, but never time out. Every little bit helps?

You should get exactly the same points/speed/cores/WU with 5.x as 6.x , so there is no disadvantage to keeping your unattended Win2k boxes running 5.x except that very old machines get low points per Watt.

No upgrade is needed to your Win2k/5.x clients, they are working great already

VijayPande wrote:I'll discuss this with our client dev team.

Any news on this front? If there will not be support, I'd like to know so I can get some 64 bit XP before it gets hard to find.

Right now, the latest version of Cosm doesn't support Win2k, so we're stuck until it does unfortunately. We'll keep the v5 clients around to handle this issue, but right now, there's not much we can do with v6.

Actually now Cosm does support it in theory, but until we can fire up the time machine to go back and locate a Win2k box (and I really miss my Apple ][e too), it's untested. Since Win2k is unsupported by Microsoft and unwise at best, Cosm on Win2k is unsupported.

I do feel bad about this but Microsoft kinda forces the issue by changing APIs in Vista (and changing them much more in Win2008). I'll be pissed when I have to upgrade from Windows 2003

If you still have a Win2k box, it may be a good idea to keep running the most stable clients on it - which is the 5.x clients. Taking down your company print/file/database server for any reason could be ... bad.

If you need an alpha tester, I'm game. I have a W2K server environment where uptime isn't critical. The software came with my 2005 Visual Studio Enterprise kit.

I got updates on our W2K Pro machines last week via Microsoft automatic updates. Its not unwise as it runs the same software as XP in almost every other instance. It's not unsupported until 2009, and maybe even longer.

From http://www.microsoft.com/windows/lifecycle/default.mspx

Windows 2000 Server GA 3/31/2000 Mainstream Support Expired 6/30/2005 Extended Support Retired 7/13/2010
Windows 2000 Professional GA March 31, 2000 Direct OEM and Retail last sale date March 31, 2004 OEM System builder last sale date March 31, 2005

More info available on Service Pack support here.

So, saying it is no longer supported depends on your view. I wouldn't call Microsoft to open a case for a W2K issue these days.

I see the point here, I just don't want to "upgrade" to the newer, more bloated, software they're selling these days. I also don't want to convert my environment to Linux because I'd be SOL for the GPU2 clients.