Page 2 of 7

Re: p2665 points/deadline?

Posted: Mon May 12, 2008 7:09 pm
by Sunin
I missed the 2 - 2.8 Xeon's Dual Cores...

That is to be read Qty (2) Xeon's which are dual cores = 4 cores @ 2.8. So a Quad @ 2.8 = 1760 PPD. That being said then yes we will definitely need to start following their suggested guidance if this is to be the future for quads. I would say then the points for the GPU2 client is out of wack since many are seeing 2k plus off of it.

/shrug...

Re: p2665 points/deadline?

Posted: Mon May 12, 2008 8:23 pm
by toTOW
Not 2.8 GHz ... 4 cores @ 2.33 GHz ;)

Re: p2665 points/deadline?

Posted: Tue May 13, 2008 2:44 am
by bruce
Sunin wrote:Am I not correct that their base benchmark system is a dual core system and thus a Quad should be able to handle 2 SMPs?

If that has not changed then I'd say a quad should be able to handle dual SMPs. All my systems run 4gig so memory should not be an issue.
According to the FAQ, the benchmark machine is a quad -- or rather a dual-dual. a 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)

It runs a single SMP client and gets 1760 PPD. If the FahCore is working as it was designed to do, running two copies Fah should give you eight copies of FahCore_xx but should give you no advantage over running one client with four copies of FahCore_xx. The policy has ALWAYS been run one copy of the FahCore per physical core.

You should expect a dual 2.33 GHz machine to get about half of the 1760 PPD.

Many have been getting more than the designated points. If you're one of those folks, consider yourself lucky, but as 7im suggests, that's probably coming to an end.
Sunin wrote:That is to be read Qty (2) Xeon's which are dual cores = 4 cores @ 2.8. So a Quad @ 2.8 = 1760 PPD. That being said then yes we will definitely need to start following their suggested guidance if this is to be the future for quads. I would say then the points for the GPU2 client is out of wack since many are seeing 2k plus off of it.
Are you saying it's too high or too low? I don't see anything inherently wrong with it (even though like any beta test, present results are not a predictor of future performance).

I just wish I could buy a Core2Penta so that I could devote one core to the GPU2 client and still have four for the SMP client.

Re: p2665 points/deadline?

Posted: Tue May 13, 2008 10:23 am
by Sunin
What I am suggesting is how can the bench system be getting 1760 for all the WU's for the SMP... I'm calling BS...

2653 = 4400 PPD on a Quad @ 3.2Ghz
3065 = 3500 PPD on a Quad @ 3.2Ghz
3064 = 3000 PPD on a Quad @ 3.2Ghz
3062 = 3500 PPD on a Quad @ 3.2Ghz
2665 = 1500 PPD on a Quad @ 3.2Ghz <I'm being generous here... I'm only getting 1450PPD on 3 quads atm because of these!

A single quad at stock should = the bench machine at least, probably more because all the cores are together. Then consider the Quad is at 3.2Ghz or more... and that is a 25% jump in power = So say 2k for a quad add 25% that is a base minimum if the bench machines is truly accurate of 2500 points... < That should be the minimum anyone ever sees with a Quad at 3.2Ghz... now some variation exists... even at 25% variation that mean points would be between 2k and 3k... that is still a huge swing but could be considered normal, but a nealry 3kPPD swing in production is NOT at all acceptable... I don't care how you justify it. Now if the 2653's were to fast we could take those out of the equation above and you still have a 2k swing in production which is over 50% difference... still not acceptable. Maybe as a thought since linux have their own WU's and Windows their own you should bench the each WU on the machine that is meant to run them. Get a Quad at stock and use that as the bench, none of this BS macbook pro 2 x 2 Xeon crap. Just my thoughts... Longevity of the project is my main concern. I'm going to support it regardless of the points, but I seem some very inconsistent stuff going on!

A lot of us have invested heavily to support Folding and we don't want to see it die because you guys are making the point system all goofy... I mean there is a reason I built a 21 box folding room and currently run 9 quads... Its because I believe in the cause!

Re: p2665 points/deadline?

Posted: Tue May 13, 2008 10:41 am
by DreadedOne509
Just curious since this is looking like a repeat from long ago.
Are we being silently pushed away from using the SMP client
with the reduced points on these work units? It would appear
that this would be an incentive to move to other cores.

Re: p2665 points/deadline?

Posted: Tue May 13, 2008 11:13 am
by zorzyk
Sunin wrote: 2653 = 4400 PPD on a Quad @ 3.2Ghz
3065 = 3500 PPD on a Quad @ 3.2Ghz
3064 = 3000 PPD on a Quad @ 3.2Ghz
3062 = 3500 PPD on a Quad @ 3.2Ghz
From my experience:

Code: Select all

Quad Q6600 @ 3.15 GHz on XP:
----------------------------------------------------
2653 = 2880 PPD (1 SMP)        4200 PPD (2 SMP)
3065 = 3000 PPD (1 SMP)        3500 PPD (2 SMP)
3064 = 2840 PPD (1 SMP)        3300 PPD (2 SMP)
3062 = 2800 PPD (1 SMP)        3400 PPD (2 SMP)
I can see that you are probably running two SMP on your quad, aren't you?

Re: p2665 points/deadline?

Posted: Tue May 13, 2008 12:03 pm
by toTOW
If you really want to compare your Quads with the benchmark machine, you must use Linux, and set it to 333*7, with the memory at 333 too (667 DDR2). This is the closest setting you can get.

Also keep in mind that in the future, the rule that a Quad core produce twice as a Dual core will likely be true ... and I see it's almost the case ...

Code: Select all

State 	Progression 	Nom 	ETA 	PPD 	PRCG 	Credit 	Téléchargé le
Inactif 	0% 	Meuh2 	16h 50mn 	1779.64 	2665 (R0, C298, G3) 	1275 points 	Il y a 26mn
Ok 	40% 	Serveur1 	1d 01h 02mn 	723.31 	2665 (R0, C126, G1) 	1275 points 	Il y a 17h 44mn
Ok 	99% 	GFX2 	17mn 	715.32 	2665 (R0, C317, G1) 	1275 points 	Il y a 1d 19h 32mn
Meuh2 is a Q6600@3.4GHz using Linux, Serveur1 is an E6600@2.6GHz using Win2003 Server and GFX2 is an E2180@3GHz using Linux. You can see that the half PPD for dual core is almost true.

Re: p2665 points/deadline?

Posted: Tue May 13, 2008 12:15 pm
by Sunin
toTOW wrote:If you really want to compare your Quads with the benchmark machine, you must use Linux, and set it to 333*7, with the memory at 333 too (667 DDR2). This is the closest setting you can get.

Also keep in mind that in the future, the rule that a Quad core produce twice as a Dual core will likely be true ... and I see it's almost the case ...

Code: Select all

State 	Progression 	Nom 	ETA 	PPD 	PRCG 	Credit 	Téléchargé le
Inactif 	0% 	Meuh2 	16h 50mn 	1779.64 	2665 (R0, C298, G3) 	1275 points 	Il y a 26mn
Ok 	40% 	Serveur1 	1d 01h 02mn 	723.31 	2665 (R0, C126, G1) 	1275 points 	Il y a 17h 44mn
Ok 	99% 	GFX2 	17mn 	715.32 	2665 (R0, C317, G1) 	1275 points 	Il y a 1d 19h 32mn
Meuh2 is a Q6600@3.4GHz using Linux, Serveur1 is an E6600@2.6GHz using Win2003 Server and GFX2 is an E2180@3GHz using Linux. You can see that the half PPD for dual core is almost true.
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 =.

I think the benchmarks should be more consistent, this will attract more people to continue to fold... I'm sure some people see their poingt go from 4.4k to 1.5k and go well its not worth it... I mean electricity is pretty expensive I'm running 200 a month right now with my 9 quads. Just some consistency to this would make most people happy.. even giving a range that all machines should be within. Plus how else do you diagnoze if an issue is with a box or its just a crappy WU?

Re: p2665 points/deadline?

Posted: Tue May 13, 2008 2:28 pm
by toTOW
Windows SMP has always been slower than Linux or OSX SMP ... the MPI architecture was originally developed for Unix systems, and Windows implementations are a bit slower (for example with p2653 on a Q6600@3.4 GHz, Linux : 3600 PPD, Windows : 3100 PPD).

Re: p2665 points/deadline?

Posted: Tue May 13, 2008 2:53 pm
by BillR
This whole point’s debate has gone on pretty much from the time we all got past work that was worth something like 5 PPD.

I even recall one post from way back when where 7im got so upset about the complaints the threat was made and carried out regarding “bonus” points and they were, as promised, lowered.

On the whole Stanford has a way they would like to see things done and that’s fine if you are an employer, you deserve to have it your way.

I’m not sure if I missed something along the way and perhaps some of you were hired and are receiving a paycheck. As of this moment I am still in volunteer status as I was from the day I signed on many years ago.

The point here is very simple actually, it costs Stanford absolutely nothing to award points. We who to the folding incur all the expense, especially those of us who own our own little farms and spent our hard earned money to build and support them.

We buy our own gear; we pay for our own power, which frankly has become a bigger burden they buying faster hardware. We initiate contests between teams, we constantly increase points and in general provide Stanford with the data it needs to continue on with the project.

For this we ask for nothing more then points. Points once again for which Stanford incurs absolutely zero expense.

This is the part where in the past 7in has jumped in and for what ever reason threatens to have the points system lowered. Maybe he is paying for the points, but I doubt that.

The truth is had we the folders not gone out a purchased new gear several times now these big projects would not be getting done but it is well known on the whole we are a competitive lot and we have always answered the challenge.

All that said, and I have said this before, Stanford should be saying thank you for the free computer time and putting some parity in the point system. Instead just the opposite happens, Stanford apparently feels entitled not only to our work but also in demanding (through coercion) how we use our own gear to their best benefit.

There needs to be some middle ground here. There is no doubt the science is of the utmost importance but the currency of the people who do the work is points.

The fact is we have too many people who have walked away from this project either as individuals or members of teams due to what they felt was a bit of abuse.

We need some commonality here folks other wise this argument which should never have gotten started in the first place will never end or if it does end it won’t be pretty.

Please don’t allow this to happen.

Re: p2665 points/deadline?

Posted: Tue May 13, 2008 3:13 pm
by Ivoshiee
Now I feel an urge to jump in. The points topics were the most prominent topics ever over the FCF and likely will become here as well. They shouldn't be, but they are. The points assignment is a tricky business.
Ideally the points system is to direct donators to directions where the science is most urgently needed. Points for the Pande Group cost no money, but indirectly they cost research time in case the points direct donators to "wrong" way. The points system is mostly KISS and will not get any radical changes until there is being proven that there is better way to do it. As always if some project is benchmarked wrongly then it should get reported and the problem will get fixed.

Btw: To my knowledge no forum moderators/admins get any pay from the Stanford nor from the Pande Group.

Re: p2665 points/deadline?

Posted: Tue May 13, 2008 4:00 pm
by 7im
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.

Re: p2665 points/deadline?

Posted: Tue May 13, 2008 4:34 pm
by Ren02
But perhaps there IS a shift at Stanford to steer the folders away from SMP? After all, according to toTOW, a Q6600@3.4GHz makes about 1780PPD with p2665. Now replace that with a non-overclocked E8200 and add a HD3870. You'll make about 2300PPD pretty much at the same power consumption level running the GPU2 client. There are only 1400 active GPU-folders and god knows how many SMP-folders. Maybe it's time to change that. :roll:

Re: p2665 points/deadline?

Posted: Tue May 13, 2008 4:34 pm
by Xilikon
I'm well aware of more details behind the scene so with this in mind, 7im, please stop taking the role of being a spokeperson for Stanford and limit yourself to moderating the forums ;)

On a side, I understand the position of Stanford that points is determined by them at their discretion and when we join, we agreed with the terms. However, I also understand those who care about points and who bitch about the very big difference between those 2665 and others WU. From what I see all around, this is a genuine issue that only Stanford is able to clarify by making a official post explaining what they are trying to accomplish and what is the future goals. Leaving everyone in the dark is not the best way to make everyone happy.

Re: p2665 points/deadline?

Posted: Tue May 13, 2008 5:02 pm
by 7im
Calming a potential flame thread is moderating. So is asking the staff to comment on this thread as I have just done. ;)