p2665 points/deadline?
Moderators: Site Moderators, FAHC Science Team
Re: p2665 points/deadline?
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...
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...
-
- Site Moderator
- Posts: 6359
- Joined: Sun Dec 02, 2007 10:38 am
- Location: Bordeaux, France
- Contact:
Re: p2665 points/deadline?
Not 2.8 GHz ... 4 cores @ 2.33 GHz
Re: p2665 points/deadline?
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)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.
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.
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).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.
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.
Posting FAH's log:
How to provide enough info to get helpful support.
How to provide enough info to get helpful support.
Re: p2665 points/deadline?
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!
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!
-
- Posts: 13
- Joined: Sun Dec 02, 2007 1:29 pm
Re: p2665 points/deadline?
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.
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.
-
- Posts: 23
- Joined: Tue Dec 04, 2007 9:12 pm
- Hardware configuration: abit IP35 PRO,
Q6600/B3 3042 MHz (9*338) / CPU VCore 1.3550V,
DDR2 4x1GB: Corsair Twin2X DDR2 800MHz CL4-4-4-12 DHX @ 845 MHz CL4-4-4-12 / 2.2V - Location: Poland
Re: p2665 points/deadline?
From my experience: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
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)
-
- Site Moderator
- Posts: 6359
- Joined: Sun Dec 02, 2007 10:38 am
- Location: Bordeaux, France
- Contact:
Re: p2665 points/deadline?
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 ...
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.
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
Re: p2665 points/deadline?
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 =.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 ...
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.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
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?
-
- Site Moderator
- Posts: 6359
- Joined: Sun Dec 02, 2007 10:38 am
- Location: Bordeaux, France
- Contact:
Re: p2665 points/deadline?
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?
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.
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?
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.
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.
-
- Posts: 10179
- Joined: Thu Nov 29, 2007 4:30 pm
- Hardware configuration: Intel i7-4770K @ 4.5 GHz, 16 GB DDR3-2133 Corsair Vengence (black/red), EVGA GTX 760 @ 1200 MHz, on an Asus Maximus VI Hero MB (black/red), in a blacked out Antec P280 Tower, with a Xigmatek Night Hawk (black) HSF, Seasonic 760w Platinum (black case, sleeves, wires), 4 SilenX 120mm Case fans with silicon fan gaskets and silicon mounts (all black), a 512GB Samsung SSD (black), and a 2TB Black Western Digital HD (silver/black).
- Location: Arizona
- Contact:
Re: p2665 points/deadline?
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...
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.
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.
How to provide enough information to get helpful support
Tell me and I forget. Teach me and I remember. Involve me and I learn.
Tell me and I forget. Teach me and I remember. Involve me and I learn.
Re: p2665 points/deadline?
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.
Re: p2665 points/deadline?
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.
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.
-
- Posts: 10179
- Joined: Thu Nov 29, 2007 4:30 pm
- Hardware configuration: Intel i7-4770K @ 4.5 GHz, 16 GB DDR3-2133 Corsair Vengence (black/red), EVGA GTX 760 @ 1200 MHz, on an Asus Maximus VI Hero MB (black/red), in a blacked out Antec P280 Tower, with a Xigmatek Night Hawk (black) HSF, Seasonic 760w Platinum (black case, sleeves, wires), 4 SilenX 120mm Case fans with silicon fan gaskets and silicon mounts (all black), a 512GB Samsung SSD (black), and a 2TB Black Western Digital HD (silver/black).
- Location: Arizona
- Contact:
Re: p2665 points/deadline?
Calming a potential flame thread is moderating. So is asking the staff to comment on this thread as I have just done.
How to provide enough information to get helpful support
Tell me and I forget. Teach me and I remember. Involve me and I learn.
Tell me and I forget. Teach me and I remember. Involve me and I learn.