p2665 points/deadline?

[Mactin]

I am going to say something a little controversial, but I am going to say it anyway.

The danger with these "low" PPD projects is that some folders might simply say : "this susks, I'm going to chuck it" ! This is real bad for science and must not be done. But the variation in PPD to some extent encourages this behaviour. A points mad participant goes hunting for a "better" WU.

I might suggest that a more common benchmarking rig be used.
The dual Xeon setup might have been a common 4 core system when it was setup, Today, using a Q6600 or Q9300 would be a more maintream platform for SMP. Since SMP is Beta, where is the harm.

Also, I point out that SMP PPD variation (2 to 1) is very mild compared to what can happen with the uniprocessor client, where on a Pentium M, I have seen a 6 to 1 ratio and on a Pentium 4, a 5 to 1 ratio.

[ChasR]

Does the benchmark machine produce 1760 ppd (stated benchmark ppd in the FAQ) on p2665? I have my doubts but don't have the hardware required to KNOW the answer.
Does the benchmark machine produce 1760 ppd on p2653? Again, I have my doubts. I think it probably produces about 2400 ppd on this WU, but don't have the hardware to know. One data point in FAHinfo.org shows production on a Woodcrest on this WU at 316/PPD/GHz/core, superior to a Q6600.
If the current value of p2665 is low for a reason other than that's how it benchmarked, Stanford should say so. If the p2653 value is high for a reason other than that's how it benchmarked, same thing. If benchmarking isn't the reason, that will end the "Changing the SMP Benchmark machine to a Q6600" thread almost immediately.

If the science is at least equal to a p3064, give the p2665 a value of 2600 points and the grousing will stop immediately.

[BillR]

Let's all calm down. Yes, p266x projects are getting less PPD than previous projects. Sucks for you, sucks for me too. But everyone is jumping to conclusions without knowing all of the facts. Everyone jumps in to complain, but they have no idea what the problem is, or how to fix it, or have good points of reference to make the comparisons that could help improve the situation.

For example, p2653 was benchmarked for dual core SMP clients. They were benchmarked with extra points and extra time on the expiration date to promote the SMP client. Some of the other projects were also benchmarked this way to help YOU, the contributor of all those precious resources. Didn't hear any complaints about that. And how was Stanford rewarded for giving that gift of points? Everyone with Quads decided to run 2 VM clients against the recommendations of the project to earn more points instead of do more science.

Obviously, Stanford was eventually going to make changes to better align the science with the points. They even said so. Now I am NOT saying that this is what happened with the benchmark of the P266x work units, but it might be a partial explanation. It could also be any or all of these clearly posted in the FAQs...

• This is a beta client, anything goes.
  Bonus points can change at Stanford's discretion, so anything goes there too.
  If you or your machine cannot tolerate even the slightest instability or problems, do not run a beta client.

How is there abuse when a beta client is at the complete discretion of Stanford? Let's try to be a little more realistic here.

We understand the complaints, as we've heard them all before. Points aren't consistent, the benchmark isn't consistent or representative of the user base, why doesn't Stanford explain what's going on in more detail? Sound familiar? I'm not even going to bother with those, as they have all been satisfactorily explained in great detail before.

If this was a stable production client, it might be a different story. But this is beta. Code changes, clients and fahcores change, points change, work units change, on a daily basis. If Stanford spent time to update us on every little development, they wouldn't get any work done. p2665 might run slow today on an A1 core, but run twice as fast tomorrow on an A2 core. Developments like this are not advertised, nor do they need to be advertised. We all know that improvements are always on the drawing board. We also know there will be bumps in the road. Please try to deal with both in a consistent manner, and a little less like fair weather friends.

So let's all take a tolerance pill and then calmly state your input on the topic in a SHORT sentence (or paragraph if you must). But please remember, a book's with of postings won't change the benchmark, may change the points system a little (but that was already planned), and may change the points a little or a lot, or not at all. It might all depend on how calm and persuasive you can be. Thanks.

I am calm, but the folding program is run by Stanford, and their actions are anything but persuasive.

If I can make preferred goals while running two clients on my quad(s) why should that in any way shape of form upset the folks at Stanford?

As to our questions on the parity of point and Stanford’s explanations, please, you are insulting everyone’s intelligence. Rhetoric does not an explanation make.

It is way too obvious that Stanford wants to make the rules and manipulate how we run our machines. This has turned a valid project into a battle of politics as in we the folders pay our taxes with work yet have no say in anything after that and you in whatever capacity you hold stick solidly with the party line.

As for the “sucks for you sucks for me too” line as well as the inference that we, the common people don’t understand the problems or have points of reference, again, please, I’ve been at this since almost day one and I have at the moment 37268 points of reference called work units all produced from my home farm.

As for a given client being Beta or not, are they not benchmarked? Is Stanford as surprised as we are at the points output?

The Beta client for the most part works. As a working client once written and tested the probably output vs. input is going to be statically predictable and as always the gross output will be determined by how fast the computer is run, not the fact that the client is in Beta.

Your comment about “YOU, the contributor of all those precious resources” is at best condescending and at worst damned insulting despite your effort to cover with the emoticon.

Be aware, I’m still very calm but I don’t like being talked down to and neither to many of the other people participating in this project.

Allow me to add, were Q6600 Quads still $1500.00 where would Stanford’s production be then. Yes, that was a rhetorical question.

Try this, X days of folding a given project on a given CPU will produce Y points. The point system requires no science, just common sense. That is what I call “realistic”.

[kasson]

Just a note to say that we do take notice of feedback from our donors and we value our donors' contributions.
There are a number of factors at play here; we are considering how best to deal with the situation. Further announcements will be forthcoming (no ETA).

[So the point of the post is mostly that we're listening and thinking. You're not being ignored.]

[Sunin]

LOL I just figured out why this has me miffed... I went to buy my 10th Quad and decided to hold off. Why you ask? You know you want to know! My decision to buy hardware is soley a $$$ to Science thing. Be it a Science to Watts (efficiency and thus long tailed $$$ part) or a Hardware $$$ to Science thing. I need to be able to understand that if I invest $400 in a new quad core system that it does X amount of Science and the immediate cost is $400 and the long cost is $20 per month (Watts used), or would i be better off with a 3850 PCIE which = X amount of Science with an immediate cost of $100 and the long cost of say $15 per month? Which in the long run produces more science? Which benefits F@H more? ultimately the thing we use to judge this is the PPD... with things goin wacky its now upset my known fact that a Quad @ $400 is the best best bang for my buck science wise. Now the GPU maybe more attractive, which in the end is fine with me I just need to know where to put my money to help support this the best I can. Also keep in mind that my decision are purely science... I don't game on these machines and this is 100% dedicated folding so its not like I'd have more than 2 of those Quads had it not been for folding!

[BillR]

Just a note to say that we do take notice of feedback from our donors and we value our donors' contributions.
There are a number of factors at play here; we are considering how best to deal with the situation. Further announcements will be forthcoming (no ETA).

[So the point of the post is mostly that we're listening and thinking. You're not being ignored.]

Dear Kasson,

Be careful or Hillary or Obama or even McCain will use that line. I meant that in all good humor of course.

I believe all anyone here is asking for is a bit of accountability and frankly I don’t think that is asking too much.

Personally I do this for the science however since the point system was put in play by the staff at Stanford it has become of more interest then before.

I guess the air of secrecy that seems to surround your end vs. our end where we share information as much as possible is the main point of contention. It causes people to wonder which hardware to purchase or change or worse, should they do either.

A for instance would be the day we all found that even though the SMP program had been written specifically for the Quad core and the staff at Stanford did their best to push that agenda running the SMP client on a Quad was little more productive then the old days of running two clients on an HT CPU.

All we ask is to be kept more in the loop and I feel that is a fair request.

[kasson]

We try to be as transparent as possible with released projects, code, etc. We don't like publicizing things that are still under development precisely because of the fluid nature of that development--plans change, projects get delayed, we find bugs, etc. But requests for more communication are understandable and appreciated.

One note about the quad-core issue: the performance of A1 work units on quad-core machines is something that took us by surprise. We expected much more efficient utilization. We've been working very hard to improve this, and we anticipate releasing an update to the A2 core in the near future that has very close to full utilization of all four (or more) cores. [One of our rare pre-release announcements.]

One other response: we understand that many folders use points yield as a way of assessing the scientific impact of their contributions. We try to keep things as consistent as we can, but there are challenges both of inter-machine variation and of balancing points/effort and points/science.

[Foxery]

Hmm... my Penryn CPU, running at a 45% higher frequency than the reference machine, is getting around 1760 PPD on this project. Rather than fan the flames, I would like to suggest that you rerun the benchmark, or an actual live WU, to verify it. (And satisfy our curiousity.)

The reference system makes a good base because it's not the most efficient hardware; dual sockets instead of a single die, and relatively slow, registered/buffered RAM. Most donors acheive higher points because we design our systems for raw speed with performance oriented platforms. Our desktop systems tend to have performance advantages over this hardware, but rarely handicaps!

One other response: we understand that many folders use points yield as a way of assessing the scientific impact of their contributions. We try to keep things as consistent as we can, but there are challenges both of inter-machine variation and of balancing points/effort and points/science.

Folks should not expect the inflated value of the infamous p2653 to be the norm.

I've always been impressed with how well thought out Folding@Home is, and how good the documentation and support is for free software. I think some people expect too much, or perhaps equate Non-profit with Open Source, which this is not. The "dev team" is responsive, but can't do everything instantly.

[7im]

Hmm... my Penryn CPU, running at a 45% higher frequency than the reference machine, is getting around 1760 PPD on this project. Rather than fan the flames, I would like to suggest that you rerun the benchmark, or an actual live WU, to verify it. (And satisfy our curiousity.)

For now, let's just say the benchmark process and benchmark system are not at issue here. Rebenchmarking, or changing the benchmark computer to a Q6600, won't change the current results.

[BillR]

We try to be as transparent as possible with released projects, code, etc. We don't like publicizing things that are still under development precisely because of the fluid nature of that development--plans change, projects get delayed, we find bugs, etc. But requests for more communication are understandable and appreciated.

One note about the quad-core issue: the performance of A1 work units on quad-core machines is something that took us by surprise. We expected much more efficient utilization. We've been working very hard to improve this, and we anticipate releasing an update to the A2 core in the near future that has very close to full utilization of all four (or more) cores. [One of our rare pre-release announcements.]

One other response: we understand that many folders use points yield as a way of assessing the scientific impact of their contributions. We try to keep things as consistent as we can, but there are challenges both of inter-machine variation and of balancing points/effort and points/science.

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.

[relic]

I have to agree with BillR and I find it beyond moronic that 7im is acting lik a fascist jackass instead of a moderator.
Grow up son, you don't need to be a fanboi...you can actually make an effort to sound intelligent.

[Foxery]

Flaming mods is defintely not necessary.

For now, let's just say the benchmark process and benchmark system are not at issue here. Rebenchmarking, or changing the benchmark computer to a Q6600, won't change the current results.

I didn't ask anyone to spend money to replace a perfectly good machine.

If you can explain why many instances of superior hardware are producing inferior results, I am all ears. Otherwise, I will cling to my Occam's Razor, and my expectation that you know what that is

[AllGold]

When I started this topic, I didn't think it was a benchmarking problem and I still don't.

Since the deadline is significantly longer, obviously it was taking longer to complete when benchmarked. I assumed it was simply a typo--that instead of 1275 it was supposed to be 2275 (or even 2751).

I also suspected at the time that only the project summary was wrong and the points total when submitted would be different but we now know the project summary and points awarded are the same, 1275.

While I can't read the minds of the folks in charge of the project, I still think it's probably a simple mistake that will eventually be cleared up rather than an intentional change of the points system on this particular work unit.

[bruce]

Its a Windows SMP client I should not have to bench it against another operating system that is not appropriate... that is like saying the GPU client should be benched on linux... two different setups... and the PPD from each should be =.

That's simply not possible.

MPI was specifically designed for Linux and it's part of the OS; the Windows versions are add-ons and they're not as efficient.

If Linux and Windows do exactly the same amount of science they get the same number of points, but it takes a different amount of time. How do you propose to make them equal?

[Ren02]

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.