Windows SMP Beta goes Open

Joe42 said:
Courtesy of uncle_fungus's excellent work fahmon is now giving me a ppd figure of 670.
Considering i can get that with the normal client i'm quite disappointed tbh... and i'm fairly sure the linux smp client is miles better...
Click to expand...

What hardware are you getting that on?

Remember that if you're comparing that to running 2x p2606 or 2x p1495, that the SMP gives high PPD consistently, whereas with regular WUs you cannot guarantee the "good" ones.
 
I have a stock E6600, Asus PB5, 2Gb ram.

VM/Ubuntu takes 15:25 per frame of a 2605 1760 point wu
native winSMP gets 17:07 per frame of a 2651 1760 point wu (over 20 frames)
 
diogenese said:
I have a stock E6600, Asus PB5, 2Gb ram.

VM/Ubuntu takes 15:25 per frame of a 2605 1760 point wu
native winSMP gets 17:07 per frame of a 2651 1760 point wu (over 20 frames)
Click to expand...

I suppose the question then becomes, which would you rather...less points but easier to run, or more points but more difficult and cumbersome.

I know which I'd choose, but I'm (mainly) a Linux guy anyway ;)
 
tbh I'd kill for a windows 64bit client as I'd guess that would have closer PPD to the linux client?
I'd also love to be able to run linux 24/7 but I can't because of work applications and other requirements (ie most if not all of the computers I borg are windows and people, while open to you putting some unabtrusive software on their PC to help find cures are less so to you installing linux on their system as well.)
 
winSMP is now on -oneunit, I've just got to convince myself I can do without flash etc. and ditch XP for native ubuntu:D... or live with VM ;)
 
uncle_fungus said:
It can do better than that.

If you've got version 2.1.5b.4 or later, I've just posted a thread on FCF to help you get it monitoring Win SMP WUs correctly.

See here: http://forum.folding-community.org/viewtopic.php?t=18570

It'll take about 30 seconds of your time to sort it out.
Click to expand...
you sir, rock!

Project : 2610
Core : Gromacs SMP
Frames : 100
Credit : 1523


-- Hal9000 SMP --

Min. Time / Frame : 22mn 30s - 974.72 ppd
Avg. Time / Frame : 22mn 30s - 974.72 ppd


thats with me playing EVE since about 2pm non stop
guessing my PPD will be closer to 1.5k without that.
 
Last edited:
VeNT said:
tbh I'd kill for a windows 64bit client as I'd guess that would have closer PPD to the linux client?
Click to expand...

Perhaps, although I'm not sure.

The only reason Linux was 64bit, was because the implementation of MPI only worked correctly in 64bit.
The OSX client is pure 32bit. and gives near enough identical performance to the Linux client.

I doubt if changing to the 64bit implmentation of MPI for Windows would actually change anything.

The most likely cause for the lower observed performance is either higher mpi overhead in windows (they are using an MS implementation AFAIK), or that the benchmarking may be slightly off, although that is probably less likely.
 
VeNT said:
would using a 64bit instruction set have any advantage?
Click to expand...

To be honest, I don't know.
I can't see how using 64bit instructions could give any tangible performance benefit for MPI, especially since the OSX client proves that 64bits aren't required for good performance.
 
uncle_fungus said:
What hardware are you getting that on?

Remember that if you're comparing that to running 2x p2606 or 2x p1495, that the SMP gives high PPD consistently, whereas with regular WUs you cannot guarantee the "good" ones.
Click to expand...
Opteron 175 (X2 4400+) with 2gb of ram.

You're quite right though, at least this does give consistently good units, whereas until recently the normal ones have been giving me more like 200ppd.

It's just i've been seeing ppd figures in the thousands for people with linux smp clients.
 
not even for the calculations?
sorry, I don't understand the ins and outs of programming and the effects of using 64bit processors on a DC basis but I'd of thought that working in 64bit rather than 32bit would have given a boost to applications like folding and seti


re PPD, from what I understand the points models are changing so that its not based on time/pc requirements but rather on the amount of work done or results produced?
 
Joe42 said:
Opteron 175 (X2 4400+) with 2gb of ram.

You're quite right though, at least this does give consistently good units, whereas until recently the normal ones have been giving me more like 200ppd.

It's just i've been seeing ppd figures in the thousands for people with linux smp clients.
Click to expand...

*cough* yes, my X2 4400+ with 1GB ram gets ~1100PPD in Linux
 
uncle_fungus said:
*cough* yes, my X2 4400+ with 1GB ram gets ~1100PPD in Linux
Click to expand...
Exactly :p
I'll be doing that soon... but the deadlines mean i need to run 24/7 i believe so i need to work on the noise a little more.
 
another issue I find with the linux, and its more of a bugbear than an issue, is that it doesn't use 100% CPU! also they said deadlines where tight but I always seemed to have 75% of the time remixing!
 
VeNT said:
not even for the calculations?
sorry, I don't understand the ins and outs of programming and the effects of using 64bit processors on a DC basis but I'd of thought that working in 64bit rather than 32bit would have given a boost to applications like folding and seti
Click to expand...
From what I gather from Dr. Pande's posts the way it works is something like this: Back in the day before float-focused instruction sets like MMX and SSE were added to the x86 instruction set floats were slow and integers were fast. Since then the performance of floats have increased dramatically. FAH mostly uses floats due to the nature of its calculations. It is faster to make use of 32, 64, and now 128-bit floating-point operations with the use of SSE* than it is to make use of long 64-bit integers. Since they can already use 64-bit floats, making special effort to use 64-bit integers is not worth it.

EDIT:
VeNT said:
another issue I find with the linux, and its more of a bugbear than an issue, is that it doesn't use 100% CPU!
Click to expand...
This is not a problem at all. Linux totals up its CPU utilization using a different method than Windows. FAH really is getting all the CPU it can get. It's not sitting at idle.
 
Joe42 said:
Exactly :p
I'll be doing that soon... but the deadlines mean i need to run 24/7 i believe so i need to work on the noise a little more.
Click to expand...

Not quite 24/7, but definately more than "office hours"
Running 24/7 takes 1.6days for a 1760point WU, and the preferred deadline is 3days.
So you could run it for as little as ~13hours per day. But that would be pushing it, especially if the machine is not dedicated.
 
Last edited:
VeNT said:
also they said deadlines where tight but I always seemed to have 75% of the time remixing!
Click to expand...
How tight are they?
That's all that's stopping me running it atm... could i complete them in time with my pc running on average 6hrs/ day?

Edit: Thanks fungus. :)
I'd struggle to do 13hrs/day.
 
VeNT said:
another issue I find with the linux, and its more of a bugbear than an issue, is that it doesn't use 100% CPU! also they said deadlines where tight but I always seemed to have 75% of the time remixing!
Click to expand...

This is due to the WUs, not the client.

p3023 used 100% CPU when you could get it, and gave you the extra PPD for your trouble.

The 100% CPU usage in Windows, could therefore be due to WUs that can split the work more evenly, or extra bloat introduced by the Windows version of the client and MPI.

@BTI, there is some idle time in the Linux client, but it varies from 2 core to 4 core and from WU to WU. Currently 2605 is running about 9% idle.
 
You must log in or register to reply here.
Back
Top Bottom