Folding Forum

I normally don't care about these point discussions but I'd thought I'd provide some data on p2665.

These two machines are very similar. The both run 2GB of CAS4 DDR2-800 RAM at 1 to 1 and have a q6600 clocked at 3.0 GHz ( 334x9 -- DDR2-668 ) so they are clocked higher than the benchmark rig. They are both running WinXP Pro service pack 2 and patched up-to-date. The PPD and times are calculated using FahMon and these rigs fold 100% with WinSMP v5.91 client. [1] is running 1 SMP and [2] is running 2 SMP.

[1] q6600 @ 3.0 GHz -- 1x SMP -- p2665 - 1286 PPD -- 23h 45m
[2] q6600 @ 3.0 GHz -- 2x SMP -- p2665 - 1051 PPD -- 29h 07m

These don't scale very well running 1x SMP since I usually get around 2300 PPD with the p30xx and around 2800 PPD on p2653. It does take about 5h 20m longer to complete a p2665 on the 2x SMP rig BUT it also will turn in a p2653 in 21h 31m. I really don't care about the points and actually believe that the values of the p2653 and p260x WUs should be LOWERED to match the p2665.

The reason I am running 2x SMP on some of my quads is because I want to be as efficient as I can with the power each rig will consume. It is my understanding that any WU I am working on isn't reissued as long as it completes before the preferred deadline.

Why does it seem like a big deal to Stanford that I choose to run 2x SMP rather than 1x SMP?

I would think that turning in TWO WUs in 29 hours would be faster than turning in ONE in 24 hours. I've been folding for a long time and only recall getting the same P (R,C,G) on two different machines one or two times. I could understand the reasoning when only the uni-processor client was being run and units would take DAYS to complete but it very rarely takes more than 29 hours to complete a unit now.

Is there any concrete evidence that a project will wrap up quicker if everyone runs a single SMP on a quad core?

I would think that the WU mix would be the same and the servers would spend more time dishing out WUs.

I can even provide the total of units turned in on a 1x SMP Duo rig vs. 1x SMP Quad rig vs. 2x SMP Quad rig. These were the only rigs that were fired up at around the same time.

1x SMP e6700 @ 2.66 = 248 units
1x SMP q6600 @ 3.00 = 301 units
2x SMP q6600 @ 3.40 = 539 units

Ren02 wrote: God damn. This is the response Stanford gets when they are even slightly more open than usual. And you wonder why we are kept in the dark.
I'd like to point out that the 30XX projects scale much better on quad-core than the 2605/2653. So improvements have already been implemented even for the newer A1 projects.

I suppose it would be possible to improve the scaling for 26XX projects as well but that would mean shutting them down, finding ways to efficiently redistribute the workload between threads and beta test the improvements for a month or two before reopening these projects to the public. It's probably faster to just let these projects finish, after all the dual core owners are not complaining.

Wow... such good arguements... Because yeah their target market with a bench machine of a 2 dual cores means the SMP was targeted for the C2D market... right... I'd bet a C2D at stock has trouble making Pref deadlines on some of the projects! So your whole arguement can be summed as follows:

1. It doesn't matter if F@H wastes our resources
2. As long as C2D owners are happy who cares

Finally what your trying to trash BillR about is the wrong point... He was mainly attacking the fact that F@H should be more proactive about providing direction and be more open up front about the issues, not wait until the pot is boiling over in order to address an issue they probably knew for a month or so! If they had kept us up to date and informed this thread probably wouldn't even exist! Its called heading off issues before they arise! Mgmt 101...

So at least get things straight before writing dribble.

Correct... The only possible outcomes of this issue is :

1-Correct the amount of points for that WU to be in line with others.
2-Explain why it's set like that and how we can take advantage of the change.

I guess that's what Stanford is struggling to decide (there is also a key factor which put a wrench in the decision process but that's not the immediate concern right now).

BillR wrote:Ok, again trying to keep this on a lite note, how could the performance of the A-1 on a Quad core take you by surprise?

Did you not run any there at the lab?

No, that's not the point Peter was trying to make. The units are benchmarked on a quad core CPU, and they didn't realise until after the a1 core was released, that a dual core CPU was just as fast due to poor scaling.
This means in effect that all a1 core units were effectively benchmarked on a quad core machine giving the performance of a dual core machine, hence the large points boost for quads running a single client, or doubling up.

Sunin wrote:Wow... such good arguements... Because yeah their target market with a bench machine of a 2 dual cores means the SMP was targeted for the C2D market... right...

SMP client was released November 2006 which is also when the first quad-cores appeared. SMP client was not written overnight though, so the software was designed and written BEFORE quad-cores became available.

I'd bet a C2D at stock has trouble making Pref deadlines on some of the projects!

Indeed. And that is an issue with the way WUs are assigned. Currently the Work Servers do not check for the donor machine capabilities and therefore they assign a WU from any project active on that server. That is something that needs to be fixed.

So your whole arguement can be summed as follows:

1. It doesn't matter if F@H wastes our resources
2. As long as C2D owners are happy who cares

No, I said that current SMP projects might have to be STOPPED for fixing the scaling issue. Projects 2605/2653 really do waste resources on quad-cores. My estimate is that about 28% of the time some of the FahCores are just waiting for the data from other FahCores to become available. For some reason you chose to ignore my comment that the scaling works much better for 30XX projects.

Finally what your trying to trash BillR about is the wrong point... He was mainly attacking the fact that F@H should be more proactive about providing direction and be more open up front about the issues, not wait until the pot is boiling over in order to address an issue they probably knew for a month or so!

Really? It read to me that the mere fact of being surprised just goes to show what incompetent hacks everyone at Stanford are.

If they had kept us up to date and informed this thread probably wouldn't even exist! Its called heading off issues before they arise! Mgmt 101...

How true.

So at least get things straight before writing dribble.

I normally don't talk about beta testing, but p2665 was beta tested, so there was no surprise involved.

BillR and others are taking kasson's "surprise" comment literally instead of figuratively. Go back and read his comment again with that adjusted point of view.

Regardless my expansion / ramp has ceased until we are made aware of the direction this is all going... I'll continue to run the boxes I have until such point that F@H does one of the following:

1. Demonstrate their uter lack of appreciation, communication, etc for the contributors

2. Demonstrate their ability to communicate, set expectations, appreciate its contributors

3. F@H does nothing

Scenario 1 results in me eventually leaving the project

Scenario 2 results in my fulfilling my 23 quad or better folding farm that is planned for.

Scenario 3 I do nothing to increase or decrease my contribution with the longer the third scenario goes on the more likely I am to slowly scale back my contribution.

Choice is up to the owners of this project...

toTOW wrote:

How do you decide the credit value of SMP work units?

Points are determined by the performance of a given machine relative to a benchmark machine, similar to the CPU client benchmark process. Before releasing any new project (series of work units), we benchmark it on a dedicated Macintosh Pro with 2 - 2.33 GHz Dual Core Xeon processors. (more specifically, 2 Woodcrest 5140 processors with 4 MB cache (each), 5 GB FBDIMM Memory (667 MHz DDR2), 1.33 GHz Bus)

We plug the results of this benchmark test into the following formula:

points = 1760 * (daysPerWU)

where daysPerWU is the number of days it took to complete the work unit.

Please note the very concept of a reference machine will mean that some WU performance will vary from the performance on your machine. Even between various Xeon processors, there are significant differences in architectures. Moreover, there are variations between WUs within a given project which can lead to speed differences.

Our goal is consistency within a given definition of a reference machine setup (described above), but beyond that, the natural variation from machine to machine and WU to WU will never allow any point system to perfectly predict what you get on your machine.

My question is did the reference machine complete this WU in 1275/1760 = .72 days? I don't think that has been answered in this topic that I've seen.

Right now my old Athlon XP 2.2ghz running non-smp client is getting more ppd than each of the cores on my E2180 running SMP, so maybe it's better that we run the non SMP client on the lower end dual cores or even all dual cores? I can certainly switch it around to do that if that's the direction the project wants us to take, but I was under the impression that the newer SMP and PS3/GPU WUs were more important for advancing the science than the older uniprocessor cores.

I thought my suggestion to verify the benchmark was pretty resonable and easy to do...

Another question: Does this project, for some arcane platform-related difference, run twice as fast on the Linux benchmark machine than on Windows clients? If so, restrict its assignment to Lunix clients, and problem solved!

Foxery wrote:I thought my suggestion to verify the benchmark was pretty resonable and easy to do...

Another question: Does this project, for some arcane platform-related difference, run twice as fast on the Linux benchmark machine than on Windows clients? If so, restrict its assignment to Lunix clients, and problem solved!

Hmm doesn't that seem sensible... ??? I mean where do you start, test the bench again. I also think if Linux has such a variance from windows that these things need to be benched on an equiv windows system. In theory F@H has always said the points are relatively close between Win/Linux and my team has found that to be within a few 100 pts... not 1760 vs 725 pts... I've ripped through something like 30 of these in the last week with my farm. Thank god I'm getting the ocassional 2653 to balance the points out... To give you an idea how it affects me... on a low point I hit 25k pts on a high point I hit 35k same farm, same specs, nothing on my end changed... You figure out what is going on!

Hello all:
Has anybody been having trouble wit large WU's and low points besides me? I'm trying to determine if it's my machine or ? I'm referring to (run 0 clone 153 gen3)this WU was taking 12 minutes per each percentage point when all previous WU's were around 8 minutes per each percentage point. That's a big jump and the points were 1275 instead of around 1750. This doesn't seem right to me. The machine is back to folding a new WU at 8 minutes so I don't think my machine has anything to do with it.
Thanks Ed


Like thread merged, PM sent. 7

Sunin wrote:Regardless my expansion / ramp has ceased until we are made aware of the direction this is all going... I'll continue to run the boxes I have until such point that F@H does one of the following:

1. Demonstrate their uter lack of appreciation, communication, etc for the contributors

2. Demonstrate their ability to communicate, set expectations, appreciate its contributors

3. F@H does nothing

Scenario 1 results in me eventually leaving the project

Scenario 2 results in my fulfilling my 23 quad or better folding farm that is planned for.

Scenario 3 I do nothing to increase or decrease my contribution with the longer the third scenario goes on the more likely I am to slowly scale back my contribution.

Choice is up to the owners of this project...

You are testing a beta client, everything is fluid.

Ren02 wrote:

BillR wrote: Ok, again trying to keep this on a lite note, how could the performance of the A-1 on a Quad core take you by surprise?

Did you not run any there at the lab?

It only took us non scientific type folders about 3 frames to figure out that the scaling didn’t work so we simply added a second client.

I’m neither angry or upset, but a statement like you just posted can’t help by shake one’s faith in the credibility of the project.

God damn. This is the response Stanford gets when they are even slightly more open than usual. And you wonder why we are kept in the dark.
I'd like to point out that the 30XX projects scale much better on quad-core than the 2605/2653. So improvements have already been implemented even for the newer A1 projects.

I suppose it would be possible to improve the scaling for 26XX projects as well but that would mean shutting them down, finding ways to efficiently redistribute the workload between threads and beta test the improvements for a month or two before reopening these projects to the public. It's probably faster to just let these projects finish, after all the dual core owners are not complaining.

How about this for an answer:

Ok, here is the deal at the moment. The other day 7im and I exchanged a number of PMs over at the other forum and I did get some answers. (this forum for this post)

The first is something VJ himself said the other day; they want and really need a cross platform client. That in itself is a major issue I have been bitching about for years now as well as the undying devotion virtually everyone in science has to coding in FORTAN.

You can Google FORTRAN till you are blue in the face and you will after all your hard work find there are only two answers.

A-It’s always been done that way.

B-It’s a very easy language to teach.

That’s it, no secrets; in the end not one person can get past those two points.

Stanford and folding are not the only ones stuck in this antique endless loop, NASA, anyone having anything to do with Astronomy, Biology and numerous other areas of research all use this common language.

One other big commonality they all share is the use of any number of the “ix” OS’s Linux, Unix, OSX (Jobs gives a lot of hardware to schools, go figure) and any other equivalent OS. There is no good reason not to use these Os’s in fact they are perfectly suited to the task.

The big bugaboo in all this is, you guessed it, Windows. There is very little written for science, or the sciences I mentioned, for Windows.

There in lies the big issue, how do you write code that performs equally on multiple operating systems? You don’t.

Those who remember the Amber work units remembers how well they performed on Intel CPUs but sucked big time on AMD. In that case it was not an OS issue it was an Intel being the assholes they are issue. They would not allow the code to be compiled for both CPU’s, only theirs. Prior to that time AMD held an obvious edge over Intel.

Ok, my point. This post is from a neutral position and those who know me know that doesn’t come lightly.

Stanford, to get the data they need is forced to write code for everybody involved or face a ton of bad commentary and or people dropping out.

What Stanford won’t ask anyone to do, pay attention here, is ask as many users as possible switch to Linux. With one OS to deal with neither science or points would suffer at all, in fact both would gain in a really big way. Running dual clients on a Quad would suddenly cut your points while running a properly written core optimized for one OS would up your points.

Now, this part is just a guess, but, my guess is Stanford won’t ask anyone to do this because this is all voluntary. So, by not being honest and upfront about this whole problem they end up pissing off more people then if they would just do it and be done with it.

Instead there is a big fear of upsetting one group of users or another. Thus we end up with the cloak of secrecy we have now which is nothing if non productive.

So, all that said it is my opinion that Stanford simply announce the change and live with the bitching. For the corporate farmers, keep what you have, they produce enormous amounts of work. Windows users can use VM with one client per quad more efficiently and even the MAC guys are covered.

There, somebody said it out loud. Nobody can please all of the people all of the time, so, Stanford, stop trying.

So, Kasson or VJ, how far off the real track am I?

7im wrote:I normally don't talk about beta testing, but p2665 was beta tested, so there was no surprise involved.

BillR and others are taking kasson's "surprise" comment literally instead of figuratively. Go back and read his comment again with that adjusted point of view.

In fact I did read his comment again, twice. I also took your word and pondered the questions you proposed.

You will find my opinion/conclusion right above this post.

I don’t think I missed the point entirely. Have a read please.

Despite the Windows platform weaknesses I doubt that there is a push for Linux nor Mac. Even Fortran is not a bigger issue because Fortran has bindings to C and other languages. The Pande Group is slowly developing a better research platform for their studies. It does mean that it is at constant beta state and things are essentially more broken than working perfectly. Writing clients, cores, library etc span in scale of years not mere months. Have patience.