Page 1 of 1

Cores

Posted: Tue Jan 10, 2017 2:48 am
by Ricorocks
How do you know what core your currently working on? What is a core?

If Nvidia 373.06 worked with Core_21, is this what was addressed by 376.48?

I'm currently on project 9040 (583,1,655), what does (583,1,655) mean?

Work unit (PRCG) what is (PRCG)

Re: Cores

Posted: Tue Jan 10, 2017 3:10 am
by Joe_H
Useful documents to read on the PG folding site are the V7 Introduction and the Simulation FAQ. These links and others are all available from the Folding Software page, also linked to at the top of the forum pages.

As for which core is being used, this is shown on the status page of FAHControl for every WU, and also is shown on every line of the log file in the form 0xNN. The NN part of the line is the number of the core, in the example line from one of my logs A4:

Code: Select all

23:24:02:WU00:FS00:0xa4:Completed 187500 out of 250000 steps  (75%)
The line has the timestamp, which WU is being processed from your work folder, which folding slot and then the status information.

Re: Cores

Posted: Tue Jan 10, 2017 11:43 am
by ChristianVirtual
Ricorocks wrote: I'm currently on project 9040 (583,1,655), what does (583,1,655) mean?

Work unit (PRCG) what is (PRCG)
A workunit like 9040 (583,1,655) ->

Project 9040
Run 583
Clone 1
Gen 655

RUN and CLONE you can read as identifier of a variant of the protein (e.g different parameter like Temperatur, different initial coordinates of atoms ...)

The GEN describe a sequential number within a variant (RUN/CLONE) above. Important is the word sequential as gen 2 is based on result of gen 1. The main reason for the quick return bonus; as it encourage us to finish a GEN as quick and complete as possible within the timelines and not delaying the start of the next GEN of a RUN/CLONE

Re: Cores

Posted: Tue Jan 10, 2017 3:12 pm
by Ricorocks
Thanks!

Question - my 32 bit folder, web control says project 9037, while at advanced control says I'm contributing to project 11403? I also saw the 0x21
my 64 bit folder web control says project 9034, while at advanced control says I'm contributing to project 10495? I also saw the 0x21
my 64 bit folder (3 machines total) match projects on each page

Why are the projects numbers different from one page to the next?

Still not so clear, what distinguishes a core 21 from an 18. How are WU's assigned to a specific core

Re: Cores

Posted: Tue Jan 10, 2017 3:52 pm
by Nathan_P
Projects are designed to be run on a specific core usually the latest one of its type, the current GPU core is core 21 and most projects run on that, however there are still some older projects around that run on core 18 as that was the latest core at that time, the older core back then would have been core 17

Re: Cores

Posted: Tue Jan 10, 2017 5:00 pm
by Ricorocks
So it's arbitrarily assigned, today it's core 21 (latest) & tomorrow it's core 22? Cores have, projects (MANY) & WU's come from projects within the core?

Based on the project what distinguishes a 21 from, say & 18?

Re: Cores

Posted: Tue Jan 10, 2017 5:45 pm
by Joe_H
No, a project is not arbitrarily assigned to use a specific core. The researchers generally will continue to use a core for projects if it meets their research needs, and only move to a new one when it offers either better performance or new features needed for their calculations. They may stay with an older core if an additional project or more is necessary and the projects are directly related to previous projects. This can simplify validation of their results. They never change cores within a project's run.

As for what distinguishes Core_21 from Core_18, that covers many things. To start, Core_21 is based on a later revision of the OpenMM software. It also includes fixes in the code for a number of issues found during use of Core_18. Those who followed the development cycle closely may weigh in with details on those.

Re: Cores

Posted: Tue Jan 10, 2017 6:21 pm
by Ricorocks
So a core is an update from previous, that contains fixes & cores contain projects, designed for that core? The same project does not occur in more than one core number?

Re: Cores

Posted: Tue Jan 10, 2017 7:24 pm
by JimboPalmer
To get consistency and repeatably of results (both very important to scientists) a researcher will use the core they started with through all the variations of a Project. Core 11 was End of Life for 3 years before all work ceased, as researchers found more analysis to do. Same for Core 15. There are still Core 17 and Core 18 work being done, even though Core 21 is the current GPU core, because researchers are not done with Projects started when they were the newest Core.

Core 11 was targeted for Nvidia Tesla GPUs, 8800 GT through GTX 290. Core 15 was targeted at Nvidia Fermi class GPUs: GT4xx to some GT 7xx CPUs. While Core 17 will run on a Fermi, it is much faster on Maxwell. I suspect, but do not know, if Core 21 has optimizations for the new Pascal Class GPUs. When all Core 15 Projects were done, some large number of GPUs could no longer Fold; new Cores needed features they did not have.

CPU cores have been much more stable, Core a4 will fold on any Pentium 5 or newer CPU. (it may not finish in time, but it runs) I think that the new Core a7 contains optimizations that favor new CPUs that support AVX2. Even if this is true, it could be years before all Projects for Core a4 are done

Re: Cores

Posted: Tue Jan 10, 2017 10:41 pm
by bruce
Ricorocks wrote:So a core is an update from previous, that contains fixes & cores contain projects, designed for that core? The same project does not occur in more than one core number?
There has been talk about an upcoming release of FAHCore_22. It will contain some new features (such as a new type of force-field), compared to FAHCore_21. If a project was started on FAHCore_21, it will continue to run on FAHCore_21, as was previously stated.

Fast-forward to a date in which both cores 21 and 22 have been released for production. If a Project Owner decides to release a new Project that's similar to ones that have been run on Core_21, he'll make a choice of which Core to use.

In a similar situation in the past, a Project that has been in production on Core_18 may still be running. If the scientist decides to launch a derivative project, he will have a choice between Core_18 or 21.

Re: Cores

Posted: Tue Jan 10, 2017 11:04 pm
by 7im

Re: Cores

Posted: Tue Jan 10, 2017 11:47 pm
by davidcoton
The Core is the code that does the simulation. It does not "own" projects, though modelling the relationship that way might work. It is more that the Core used is an attribute of a Project. Once the Core is defined, for scientific consistency it doesn't change -- if it is required to re-run the data on a new core, a new project is defined (this is done to test new cores, for example). Cores do have a revision number but these tend to be stable once a core is released (bugs uncovered by driver version changes are a possible exception).
There is no fixed relationship between Driver versions and Cores. The driver will abstract the hardware interface, normally later revisions are backwards compatible. In most cases a Core will work with a large range of Driver versions, though some work better than others. In theory (though I think perhaps not in practice) a Core using the OpenCL interface will run on both AMD and NVidia hardware.

Re: Cores

Posted: Wed Jan 11, 2017 12:58 am
by Ricorocks
"The 'core' is the program that performs the calculations." Cores can/are designed for specific GPU's, to take full advantage, of the improved GPU's. Scientist's can choose which core to assign there projects to. So what powers the cores 'calculations' is the donor. I think I've got it, if not well...

Thanks Messrs Joe_H, ChristianVirtual, Nathan_P, JimboPalmer, Bruce, 7im, & davidcotton

Re: Cores

Posted: Wed Jan 11, 2017 5:04 am
by bruce
Ricorocks wrote:Cores can/are designed for specific GPU's, to take full advantage, of the improved GPU's.
I don't think that's quite the way I would word it.

When a new family of GPUs is introduced, it's the responsibility of the Vendor to alter/add-to the drivers in ways that will allow programs (like a FAHCore) to take full advantage of the features of the improved GPUs. In theory, (and thanks to the Drivers) any program (such as a FAHCore) which is written to a standard API (OpenCL or CUDA) should be able to use the new GPU features without being reoptimized or otherwise updated. In some instances, the FAHCore may be able to be further optimized without breaking the performance of older GPUs.

In the case of the recent issues with the NVidia drivers, additional driver support was needed, both for the new GPUs and for the new features that they contain. This lead to the 375/376 family of drivers. NVidia's main thrust of the new hardware was to bring advanced video capability to state-of-the-art games so they called these drivers "game ready" but if you check, there have been many, many revisions aimed specifically at the video of specific games.

There were no announced changes to the OpenCL API so from the perspective of both NVidia and FoldingAtHome, the new drivers should not have broken FAHCore_21. (It still supports OpenCL Compute:1.2)

Obviously that didn't go as planned, and jointly, they're still working on several approaches that may allow them to build a permanent revision of the drivers which can replace the current hot-fix driver.
See viewtopic.php?f=24&t=29556