-bigadv on x6

[Zagen30]

Now, my i7 @ 3.8 GHz does roughly that performance. If 6 physical cores can almost identically give the same performance as 4 physical cores/8 threads on a bigadv WU, then the x6's should be able to complete them.

I'm not sure that you can make those generalizations and be accurate. There are just too many architectural differences between an X6 and an i7 and folding is a very optimized application that very small differences in things like the FP, cache, or inter-process/thread communication can make significant differences in performance. Now supposedly (in an earlier thread) there was one person with a highly OC'ed X6 claimed that he could successfully return a -bigadv. I don't remember anyone else that has reported success. I really think testing is much more valid than extrapolation here.

That's why I said if. I don't know whether 6 AMD cores have equivalent performance to 8 Intel threads on bigadv WUs when both are at clock speeds that give similar performance on normal a3's.

[bruce]

I don't think you guys understand what i was saying earlier. No amount of talking about performance is going to change the way this works.

The Assignment Server bases it's decisions on the information supplied by the client. Your discussions are centered about about a concept called performance. Performance is only indirectly related to getting the AS to assign or not assign bigadv is The client DOES NOT KNOW the performance of your system.

Imagine the following anthromophosed discusson between your client and a server:
Client (to AS): I need some SMP work.
Server: What's your system's performance?
Client: I'm not programmed to answer that question, Dave.
Server: What's your cumulative GFLOP rating?
Client: I'm not programmed to answer that question, Dave.
Server: What's your cumulative GHz rating?
Client: I'm not programmed to answer that question, Dave.
. . . Aside to "orion" your fuzzy math makes sense to humans, but not to the client :eugeek:
Server: (Gosh, you're not very smart.) How many cores do you have?
Client: I have <assume the proper value is given here> cores. (I think I would be offended if I were programmed to know what that means.)
Server: Ok, you can get your WU from this work server: xx.xx.xx.xx
Client (to xx.xx.xx.xx.xx): I need some work. The AS sent me to you. I have <...> cores.
Server: Here's your work..........

An i5 is essentially the same hardware as the i7 except that it doesn't have HyperThreading. How much performance is gained from HyperThreading has been subject to many debates, but it's anywhere from maybe 25% all the way down to zero, depending on the application. Although it may improve the performance of FAH, let's assume without proof that it's close to zero. Would an i5 be able to meet the dealines. With that assumption, the answer is "of course" . . . but the assignment server does not distinguish between one 4-cored system like the i5 and another 4-cored system like the x4. With the information available to the server, all 4-cored systems get the same assignments. All 8-cored systems get the same assignments. The server does not understand that a system with 8 real cores is somehow different than the i7 even though the performance is radically different.

The decision is made exclusively based on the number of cores -- not on any sort of performance rating and not on the basis of who can complete the WUs and who cannot. If you have an x6, no matter how well you are able to overclock it will still be treated as a 6-cored machine. When you get an x8 -- even if it the early version happens to have very low clock rates and it ends up under-performing your overclocked x6, it will get the assignments based entirely on core-count.

The client and the server do not know if your performance is high enough to meet the requirements or not, it only knows if you have a certain number of cores.

[P5-133XL]

If an x6 can complete a -bigadv WU in time why not let them fold it? More science is getting done that way.

If PG wants to stay true to the "8 core and above" class of systems then fix it so that a 4 core i7 can't get a -bigadv...but that wouldn't be right because some of those systems can complete a -bigadv in time. The science will progress faster if more WU can be done, and if an x6 can do it all the better for us all.

As I said before, it was never intended that i7's or X6's be able to run these. -bigadv's were designed for multi-socketed monster servers. If Stanford weakened the standard and officially said X6's and i7's are now the market for these WU's then they can't create a WU that X6's and i7 can't finish in time. They would have capped the maximum work that a WU can require to something below that which they originally intended.

As it is now, if they ever produce a WU that an i7 could not complete in time, they could truthfully say that you were never supposed to run bigadv's. When the i7 crowd complains, and they would, they really don't have a leg to stand on. The fact that they could complete the old WU's that means nothing for it was never intended that bigadv's were for them.

If Stanford officially lowers the standard then it would be Stanford that wouldn't have a leg to stand on when those bigger WU's come online. The i7's and X6's would have a legitimate gripe that they invested in all these machines to run bigadv's and later they couldn't.

As processing power increases over time then it is definitely better if Stanford does not artificially cap the maximum difficulty of their WU's to i7/X6 capabilities. It is much more likely than not that sometime in the future those big WU's that an i7/X6 can't complete will be created. So why create a promise that they are unlikely to be able to keep? It may make some people happy now but they will create a lot more anger and alienation later.

[PantherX]

...

...Well after some closer inspections, one of my cores wasn't at 4.1Ghz. Looks like this bug that PantherX was referring to in an earlier post that 'slows the workunit down in a non-linear manner' certainly does slow things down! I'm happy to see a >10x increase in PPD for just changing one BIOS setting. ...

...

I would like to clarify that there are two "issues" with a3 Cores:
1) When the FahCore_a3 process a WU and if the CPU cycles are taken from it by another application, it will cause the WU to slow down in a non-linear fashion. However, this was observed with v2.19 and I have not read any official remarks where this is fixed in v2.22.
2) AFAIK, the FahCore_a3 will sync up its speed with the slowest CPU speed that is assigned to it regardless of the fastest CPU speed. (I think this is what bradpt was referring to rather than the previous issue)

I would like to add that as this is officially a trial and the Client is in BETA Stage. The Final Client will always be subjected to changes. All these talk about x6 being comparable to i7 is based only on a single Project 2684. The real reason of this category of WUs to exist is for the ubber-high end hardware that a handful (when compared to the rest of the F@H Donors) of Donors are willing to fold on by excepting the conditions that Standford has laid down. In the short-term, I guess it may work but in the long-term, both of these processors will be outperformed by faster ones.

[orion]

If Stanford weakened the standard and officially said X6's and i7's are now the market for these WU's then they can't create a WU that X6's and i7 can't finish in time. They would have capped the maximum work that a WU can require to something below that which they originally intended.

I wouldn't call it "weakening" I would call it adjusting. A team M8 of mine is running a 2684 on his 2p now with the windows client. It will not make the preferred deadline where's it would under LINUX. So because of this (and I'm sure he is not the only one) should PG adjust their minimal core count to 12? I would hope not, it wouldn't further the science by locking out all the real and virtual 8 core systems that are fine on LINUX.

. . . Aside to "orion" your fuzzy math makes sense to humans, but not to the client :eugeek:
Server: (Gosh, you're not very smart.) How many cores do you have?
Client: I have <assume the proper value is given here> cores. (I think I would be offended if I were programmed to know what that means.)
Server: Ok, you can get your WU from this work server: xx.xx.xx.xx
Client (to xx.xx.xx.xx.xx): I need some work. The AS sent me to you. I have <...> cores.
Server: Here's your work..........

I was thinking of it more in this line, the AS voice is played by Frau Farbissina and the client by Oliver

AS: what do you want?
Client: a new WU please,
AS: how many cores do you have?
Client: I think I have 8 cores.
AS: you LIE!
Client: but if I knew what that was I'm sure that I would have 8 cores.
AS: you are a stupid little client, go to server xx.xxx.xxx.xxx to get your WU!

Fuzzy math is what it is, looks good on paper and is probably right but..........

[P5-133XL]

If Stanford weakened the standard and officially said X6's and i7's are now the market for these WU's then they can't create a WU that X6's and i7 can't finish in time. They would have capped the maximum work that a WU can require to something below that which they originally intended.

I wouldn't call it "weakening" I would call it adjusting. A team M8 of mine is running a 2684 on his 2p now with the windows client. It will not make the preferred deadline where's it would under LINUX. So because of this (and I'm sure he is not the only one) should PG adjust their minimal core count to 12? I would hope not, it wouldn't further the science by locking out all the real and virtual 8 core systems that are fine on LINUX.

You can call it adjusting, but that is just semantics. The point is still that if Stanford officially allows the less capable HW than it originally intended it would still effectively cap the maximum WU that they could issue for bigadv's and that is a bad thing. So it is not going to happen.

No, allowing these low-end machines run bigadv's does not help the science. These machines can run the A3's just fine so the science is not harmed by excluding them from bigadv's. However, forcing a cap on the difficulty of WU's by officially allowing these low-end machines to run them prevents Stanford from issuing WU's that these low-end machines can't complete. So Stanford would be prevented from doing the science that these bigadv's were designed for and that is a definite harm to the science.

P.S. Most people think that X6's and i7's are high-end machines but for the purposes of bigadv's they are low end hardware. Bigadv's were designed to take advantage of dual i7's (as a minimum), quad i7's, or even octo i7's (Xeon equivalents).

[leexgx]

if it was not for i7 and lower end dual Quad i7 Xeons there would not be many running this project at all apart from users who have money to burn

until amd bring out an 8 core CPU out they are not likely going to change it

do Norm A3 work units or buy an i7 setup or Dual i7 Xeon Quad or 12 core opteron setup (you can make 2-4 i7 systems for the price of an server based setup normally)

[orion]

If Stanford weakened the standard and officially said X6's and i7's are now the market for these WU's then they can't create a WU that X6's and i7 can't finish in time. They would have capped the maximum work that a WU can require to something below that which they originally intended.

I wouldn't call it "weakening" I would call it adjusting. A team M8 of mine is running a 2684 on his 2p now with the windows client. It will not make the preferred deadline where's it would under LINUX. So because of this (and I'm sure he is not the only one) should PG adjust their minimal core count to 12? I would hope not, it wouldn't further the science by locking out all the real and virtual 8 core systems that are fine on LINUX.

You can call it adjusting, but that is just semantics. The point is still that if Stanford officially allows the less capable HW than it originally intended it would still effectively cap the maximum WU that they could issue for bigadv's and that is a bad thing. So it is not going to happen.

No, allowing these low-end machines run bigadv's does not help the science. These machines can run the A3's just fine so the science is not harmed by excluding them from bigadv's. However, forcing a cap on the difficulty of WU's by officially allowing these low-end machines to run them prevents Stanford from issuing WU's that these low-end machines can't complete. So Stanford would be prevented from doing the science that these bigadv's were designed for and that is a definite harm to the science. I can't see how it doesn't.

P.S. Most people think that X6's and i7's are high-end machines but for the purposes of bigadv's they are low end hardware. Bigadv's were designed to take advantage of dual i7's (as a minimum), quad i7's, or even octo i7's (Xeon equivalents).

If an x6 or an i7 can complete a -bigadv WU before the preferred deadline it does help the science.

As I said above, since some 8 core systems can't finish a -bigadv WU in time under windows now, should they all (8 core) not be allowed -bigadv then?

[orion]

if it was not for i7 and lower end dual Quad i7 Xeons there would not be many running this project at all apart from users who have money to burn

until amd bring out an 8 core CPU out they are not likely going to change it

do Norm A3 work units or buy an i7 setup or Dual i7 Xeon Quad or 12 core opteron setup (you can make 2-4 i7 systems for the price of an server based setup normally)

They do have one, it'e called Magny Cours.

[leexgx]

(Home use CPU vs server CPU) price there as well

[rickoic]

Newegg has some AMD's with 12 cores.

Fold on
Rick

[P5-133XL]

If an x6 or an i7 can complete a -bigadv WU before the preferred deadline it does help the science.

As I said above, since some 8 core systems can't finish a -bigadv WU in time under windows now, should they all (8 core) not be allowed -bigadv then?

You really aren't paying attention. Open your mind and then lease try reading my posts and then so some thinking about them rather than just doing a knee jerk reaction.

If x6 or i7's become the standard for bigadv's then Stanford can not issue WU's that prevent these machines from finishing. Therefore the whole purpose of the bigadv program (which is to use those multi-socketted i7 Xeons to their full effect) is defeated and that harms the science that Stanford can do. All those x6 and i7's can do the A3's just as productively and thereby not harm the science that bigadv's could do if the i7's and X6's are not in the bigadv program.

[orion]

If an x6 or an i7 can complete a -bigadv WU before the preferred deadline it does help the science.

As I said above, since some 8 core systems can't finish a -bigadv WU in time under windows now, should they all (8 core) not be allowed -bigadv then?

You really aren't paying attention. Open your mind and then lease try reading my posts and then so some thinking about them rather than just doing a knee jerk reaction.

If x6 or i7's become the standard for bigadv's then Stanford can not issue WU's that prevent these machines from finishing. Therefore the whole purpose of the bigadv program (which is to use those multi-socketted i7 Xeons to their full effect) is defeated and that harms the science that Stanford can do. All those x6 and i7's can do the A3's just as productively and thereby not harm the science that bigadv's could do if the i7's and X6's are not in the bigadv program.

I believe you are trying to read way too much into my post, the only knee jerk reaction is in your assumption in what I'm posting.

I also believe that PG meant for the -bigadv WU to be folded on more than multiple i7 Xeons. There is a host of 4, 6, 8 and 12 core AMD 2P/4P/8P that can do just as good as or even better than Intel 2p systems.

Yet you haven't answered my question. If (and it looks that way) a 2p (also, we aren't talking all 2p's here) can't finish a 2684 before the preferred deadline, using your argument, shouldn't all 2p's be disqualified from -bigadv WU's then?

[John Naylor]

There will always be some systems which are incapable of meeting deadlines despite meeting the official requirements. Some of the slowest dual cores available when the SMP client first appeared were too slow to fold SMP units, so it is of little surprise to me that some of the slowest 8-core systems also fail to meet the deadlines for the bigadv project. I also read somewhere that some people could get heavily overclocked Pentium 4 HTs to run the first batch of SMP units, just as i7s can run this first set of bigadvs if they have HT enabled.

The Pentium 4 quirk did not lead to a restatement of the rules for SMP to explicitly include support for them, and they were quickly rendered incapable of folding SMP units by increased unit sizes. I suspect that the same will happen to i7s, and this is what P5-133XL is trying to say. By lowering the boundaries to officially include support for i7s or X6s, the Pande Group are restricting the maximum size of the unit they can release when bigadv units inevitably grow in size to match the latest hardware in 2 or 3 years time. A class of units explicitly designed to use the latest hardware is aimed at a moving target, and that target is only ever going to be moved upwards. This is why I think it would be a bad idea to explicitly add support for i7s or X6s, even if it would allow more units to be completed in the present. In the longer term it may prove a hindrance.

[orion]

John, I do understand fully what P5-133XL is saying. We are in the midst of larger WU's change over now, A2's to A3'.

I've been folding since 2004 so I've seen allot come and go. I remember when talk first started up about GPU folding and if it was possible. How AMD systems couldn't get QMD WU's because they weren't Intel systems. How PG really only wanted SMP's on true 2 core systems and not use HT to fold with, but we found out that it didn’t hurt the science and now it's a part of life...etc...etc

In reality this is all moot point, PG will not change it.