Folding Forum

Is it currently possible to determine exactly (or relatively close) how many dual core processors (or VMs) are participating in the SMP Beta project?

What is the current average turn in time for SMP Beta Work units on average per remaining time left? Eg. 25% are turned in with >75% of the time left. %50 of WU are turned in with >%50 left etc.

Does running a Dual Core processor (or VM) hurt the data needed for the SMP project?

Please do not refer me to the Wiki. Pretty much all the links in it are now dead since the other forum appears to be gone. My preference in answers would be yes or no. and data to back it up. Trying to be specific.

I want to know if my 3 SMP Dual Core setups are hurting more than they are helping. Thanks!

I would guess that the majority of people running the SMP clients are doing so on dual core CPUs. As long as your making the preferred deadlines of any WUs your doing, your helping.

Also, the client detects if you have 2, or 4 cores and the assignment servers can assign WUs based on that info. So it's up to Pande Group to send the appropriate WUs to the proper machines.

ICE_9 wrote: Does running a Dual Core processor (or VM) hurt the data needed for the SMP project?

Obviously all donations are welcomed. However, those are two different questions. Those running on Dual Core are running the fah client as optimally as they are capable. BUT, those running 2 VMs on a Quad are chosing to help the project less than optimally. The project recommends one fahcore per cpu core.

ICE_9 wrote:Please do not refer me to the Wiki. Pretty much all the links in it are now dead since the other forum appears to be gone. My preference in answers would be yes or no. and data to back it up. Trying to be specific.

Why not refer you to the WIKI??!! It makes VERY little difference that links in the WIKI to the FC Forum are not currently working. The valuable data from the Forum was placed in the WIKI, and the links simply provide a credit to the user who posted that info, or provide additional context for that same info. Don't let BAS put any silly ideas in your head about the WIKI being any less without those links.

No silly ideas here. The Wiki has info in it, however, background discussions and 9+ page debates definitely help the 1 single page on the Wiki. The links provided minute details that may have been passed over in the Wiki that some may feel were important.

I guess its very confusing to me at the moment. I have not really seen any info predominately spread in the forum about the SMP client. Out of the last 4 announcements, 3 were to download the new client because of beta date expiration, and the other was for the v6 enabled one. I am not quite sure of when the SMP client started, but I have my oldest SMP system working on it's 139th WU right now. It is averaging close to 2 days per WU. I am leaning to believe that their are not enough donators to get this out of beta or that possibly development has stalled.

I know VJ's resent post about changes about to happen. I know they will be gradual. I think the biggest thing will be when Beta is dropped and a client is for real and stable.

Obviously all donations are welcomed. However, those are two different questions. Those running on Dual Core are running the fah client as optimally as they are capable. BUT, those running 2 VMs on a Quad are chosing to help the project less than optimally. The project recommends one fahcore per cpu core.

Ok my brother just set up 2 SMP clients running on a quad with 'affinity' or something like that.

You are saying this is not a good thing?

So higher PPD is not necessarily a good thing for the project?

ICE_9 wrote:I am leaning to believe that their are not enough donators to get this out of beta or that possibly development has stalled.

When the SMP client was first distributed to Linux and MacOS people, there was a statement made about perhaps it is not possible to bring out a SMP client for Windows. Lots of Windows users complained, as you might expect. Not long after that, a version for Windows was made available, but with some reservations.

From that information, I think it's fair to assume that making the Win-SMP code solid/reliable may still not be possible but I'm sure someobody at Stanford is really trying. If you want to call that "stalled" I think you may be accurate, but it puts a pretty negative slant on the difficulty of the development needed.

There have been several suggestions that people could help by "fixing" the networking problems encountered with the open source version of mpiexec and as far as I know, nobody reading this forum has stepped up. That may not be the only problem that needs fixing, but it's certainly a big one.

socceronly wrote:So higher PPD is not necessarily a good thing for the project?

The present points system is not optimal under all conditions. It doesn't encourage people to fold in the way that Stanford wants us to. Dr. Pande's statement that changes are coming would seem to indicate that they plan to fix it quite soon.

Preferred and final deadlines should be all that is necessary to provide the framework within which people can select the appropriate client for their usage and configuration. Attempting to dictate how people Fold, if they're already meeting said deadlines, is a risky proposition.

7up1n3 wrote:Preferred and final deadlines should be all that is necessary to provide the framework within which people can select the appropriate client for their usage and configuration. Attempting to dictate how people Fold, if they're already meeting said deadlines, is a risky proposition.

Don't the deadlines already dictate how people fold? Slower dual Xeons and dual P3s can't run the SMP client.

Even the CPU client needs to be at least a P3 or above, with SSE, to meet the deadlines.

Big WUs get bonus points, so people are upgrading to more ram to run that with the client option. SMP WUs score well on dual cores, so people are upgrading from P4s a little sooner to take advantage of the higher PPD.

What's the difference in adding one more incentive?

I don't disagree that changes to the points system won't be thoroughly discussed, but Stanford already determines a lot in how you fold, but not everything. An incentive is just that, an incentive. You can choose to take advantage of the incentive, or don't. Stanford is not "dictating" anything.

codysluder wrote:

socceronly wrote:So higher PPD is not necessarily a good thing for the project?

The present points system is not optimal under all conditions. It doesn't encourage people to fold in the way that Stanford wants us to. Dr. Pande's statement that changes are coming would seem to indicate that they plan to fix it quite soon.

Hmmm.

I am newb, but I can't see any fault with the following or understand science side of why this would be bad. (and maybe it varies on the project too)

Unless there is some kind sequence involved that is allocated to a computer and things get confused in the allocation process when one computer is running two clients. I think that came out the way I wanted to say it....lol

Project 2653:

Dual Core Laptop: 36 hours
Quad Single Client SMP: 19 Hours
Quad Dual Client SMP: 26 hours X2

It is still doing two work units before the one on my laptop, and all within the dealine.

If it is better for the project for my brother to only run one client and get rid of the affinity thing, then I will have him do so.

Points are fun, but I would rather it maximized the usefulness.

7im wrote:

7up1n3 wrote:Preferred and final deadlines should be all that is necessary to provide the framework within which people can select the appropriate client for their usage and configuration. Attempting to dictate how people Fold, if they're already meeting said deadlines, is a risky proposition.

Don't the deadlines already dictate how people fold? Slower dual Xeons and dual P3s can't run the SMP client.

Even the CPU client needs to be at least a P3 or above, with SSE, to meet the deadlines.

Big WUs get bonus points, so people are upgrading to more ram to run that with the client option. SMP WUs score well on dual cores, so people are upgrading from P4s a little sooner to take advantage of the higher PPD.

What's the difference in adding one more incentive?

I don't disagree that changes to the points system won't be thoroughly discussed, but Stanford already determines a lot in how you fold, but not everything. An incentive is just that, an incentive. You can choose to take advantage of the incentive, or don't. Stanford is not "dictating" anything.

Perhaps I'm still just a bit ruffled from that last thread, so came into this one from the perspective that the changes implemented might be used to 'de-incentive' people from finding solutions that prioritize stability while maintaining productivity (LinSMP in Windows via VMware).

gwildperson wrote:Apparently you believe that you know more about the scientific needs of F@H that the head of the project. Doesn't it mean anything to you that (!) Vijay Pande has ASKED US NICELY not to run more than one FAHcore per CPU-Core, and (B) He's saying that there will soon be some changes to the points system (which, from what has been said will probably dis-incentivize people who don't follow his request).

The previous thread was locked because you and others continued to argue about this in spite of requests to stop. Why are you persisting here?

Certainly stability will always be better than instability but that has nothing to do with running "too many" clients.

I am floored by this anti-discussion, what you label 'arguing', attitude. Constructive criticism and open dialog is an important tool toward discovering new ways of looking at things. The Folding@Home project is a research project and, having talked with Dr. Pande directly more than once, have no doubt that they appreciate constructive dialog from every perspective. It is my opinion that stifling discussion does much more to damage research than airing of any 'hey wait a minute, have you thought of this?' perspective.

My entire perspective here is based on stability, so please do not discount this. I run my workstations in a Windows environment, and a few of them are perfectly suited for running the SMP client. I aided for many months in the beta testing process for the WinSMP client and, when the (IMHO ingenious) method for running LinSMP in a Windows environment was discovered I switch because it freed me from the frequent need to check all of my boxes and perform all the steps to restart the WinSMP client on those that had failed for one reason or another. This allowed me to continue allowing these perfectly spec'd computers to contribute to an important subsection of the project.

So no, I am absolutely not disregarding anything Dr. Pande says in regard to the team's hardware/client configuration preferences. And I suspect he has a better eye for the overall situation than some might assume. But that doesn't infer that I won't share my perspective whenever I feel that it might be contributive to the discussion.

Doesn't it mean anything to you that (!) Vijay Pande has ASKED US NICELY not to run more than one FAHcore per CPU-Core,
--------------------------------

If this is the case, I will have my brother change his quad core to running a single SMP client.

This is better for the project? Then no problem.


EDIT: Can I get some clarification here?

The above sentence says 'one FAHcore per CPU-Core'

Does that mean one Client per CPU? If I have a quad core, which is effectively 2 dual cores.... is running the SMP client twice on a quad core what Dr Pande is asking us NOT to do?

Or is he asking us not to run two clients accessing a single core......

Now I have confused myself...LOL!

socceronly wrote:The above sentence says 'one FAHcore per CPU-Core'

Does that mean one Client per CPU? If I have a quad core, which is effectively 2 dual cores.... is running the SMP client twice on a quad core what Dr Pande is asking us NOT to do?

Or is he asking us not to run two clients accessing a single core......

Now I have confused myself...LOL!

The current SMP client is hard-coded @ four threads, each thread represented by a FAHcore . So it is designed specifically to be utilized by quad-core processors, one CPU core for each FAHcore process.

While many dual core processors are sufficiently fast enough to run SMP, they're doing so by having one CPU core per two FAHcore processes. Those running dual quad systems must run dual SMP in order to fully load the cores due to the four thread hard code. In both cases, whether you're running SMP on a dual or multiple SMP on a dual quad, you're not using the client in the specific manner for which it was designed (the hard coding is part of the beta process, and should eventually be removed as client development progresses).

7up1n3 wrote:

socceronly wrote:The above sentence says 'one FAHcore per CPU-Core'

Does that mean one Client per CPU? If I have a quad core, which is effectively 2 dual cores.... is running the SMP client twice on a quad core what Dr Pande is asking us NOT to do?

Or is he asking us not to run two clients accessing a single core......

Now I have confused myself...LOL!

The current SMP client is hard-coded @ four threads, each thread represented by a FAHcore . So it is designed specifically to be utilized by quad-core processors, one CPU core for each FAHcore process.

While many dual core processors are sufficiently fast enough to run SMP, they're doing so by having one CPU core per two FAHcore processes. Those running dual quad systems must run dual SMP in order to fully load the cores due to the four thread hard code. In both cases, whether you're running SMP on a dual or multiple SMP on a dual quad, you're not using the client in the specific manner for which it was designed (the hard coding is part of the beta process, and should eventually be removed as client development progresses).

LOL! Ok.

1 Q6600 = 1 SMP Client. This is what is wanted?

But should I run the SMP on my dual-core laptop? (or any dual-core machine?)