Folding Forum

huyetma wrote:RR, lol
I can feel your pain. I have 2 sr2 they all can not get bigadv.
Probably need to shutdown to save electric, while AS out of commission.

Technically speaking the Assignment Servers are working find. It's a Work Server that's out of commission. Your client contacts as Assignment Server which assigns you to a Work Server. As GreyWhiskers explained above, there are several different Work Server which are serving bigadv WUs. Only one of those Work Servers is out of commission.

Unfortunately, all of those work servers, combined, have fewer Trajectories than the number of people who are competing for bigadv WUs. It's the serial nature of the trajectories that causes them to be perpetually almost out of WUs. Every time somebody completes a WU, the server generates the next WU for that trajectory. It is immediately assigned to some lucky person, leaving some unknown number of unlucky people being told that there's no bigadv work for them.

My point is that the Pande Group has no method of telling folks that the demand exceeds the supply. Adjusting the minimum number of cores from, say 8, to say 12, on some (or all) of the existing projects would provide a consistent answer to all the i7's and dual-quads: "We have no work for you right now" rather than the inconsistent "We only have enough WUs for a small percentage of lucky people"

Switching your machine to Standard SMP or shutting it down temporarily is exactly what needs to happen right now -- until the new projects that are almost ready to release complete the necessary testing steps.

Bruce;

While all the study and discussion of trajectories is very enlightening and informative (I have gained a limited understanding of how things happen in my 5 years of folding), it misses out on addressing the elephant in the room.

Why is it that PG does not have a 'cache' of tested and approved projects which are ready to be released when there is a lack of work for any particular client?

While I realise that projects come to an end, there surely is a pipeline of work coming where the researchers and PG know they want to look at, and then have something 'up their sleeves' to release in short notice (within hours) which has already passed all the processes required to release a project to the general folding community to crunch.

I realise that doing something like this will require more effort and probably more servers, and also likely slow down the 'priority' projects a little, but we just want to crunch. When the work is not available, we are upset because we feel we are not valued by PG to keep us 'fed'.

It could even be a side project, or something that a researcher just has a hunch about or wants to get an idea if it is worth looking at - like a 'pre-project' of limited trajectories and not a full level project. Ideally this could be AS'd in-between the other projects being completed and the next section of it being released, or a completely new project coming online.

Back to my point above. What's important - to get the entire ensemble of folders to attack the problem as quickly as possible - or to be "fair" to the high power folders? Cutting down on the number of folders would seem to slow down the overall scientific return, possibly compromising rapid finish of the science projects. Unless, of course, the scientific community can't keep up with all the folding results, and one of the objects is to put a damper on the rapidity of WU completion to let the back end catch up.

It's the serial nature of the trajectories that causes them to be perpetually almost out of WUs.

Then, maybe this needs to be an official announcement.

Switching your machine to Standard SMP or shutting it down temporarily is exactly what needs to happen right now -- until the new projects that are almost ready to release complete the necessary testing steps.

@greywhiskers: The problem with the 100 top folders plus 500 i7 folders is if each of the top 100 folders take 1 day to complete a work unit, 100 steps can be completed in 100 days.

If 500 i7 folders take on average 2 days to complete the work unit, then it will take longer for each trajectory to complete - for every 2 one day work unit returns 5 work units will issued to i7s and take 2 days. Therefore every seven steps will take 12 days, or 168 days to complete 98 steps...

I would presume that PG don't have a cache of projects to roll out when supply is low because they're best to release projects as soon as possible, not hold them back. I do recall the last time there was a shortage of work units that PG worked hard to make sure there was a greater pool. In this case it is the unfortunate need to shut down a server in order to undertake an upgrade of the software...

Seems like it would seem prudent to increase the core requirement when the number of wu's available falls below a __ % of requests for an hour, 3 hours, or some other criteria, like when a known shortage has arrived.

Make it so 8 cores and less get assigned smp and the remaining bigadv WU's go to 12 cores, or 16 cores, or 24 cores, what ever will most quickly and efficiently keep the flow going.

When things improve, reset to allow those turned off to get bigadv wu's again.

Beats everyone waiting around thinking, will I get one or do I switch over?

Mitsimonsta wrote:Why is it that PG does not have a 'cache' of tested and approved projects which are ready to be released when there is a lack of work for any particular client?

Research doesn't work that way. FAH, while very important to the research is still a relatively small part of the total process. Research requires a great deal of though and hard work before, during, and after the portions that can be processed by computer.

A researcher gets an idea. (S)He formulates a theory. (S)He devises a method of testing the theory. Tests are prepared and run. (S)He analyzes the results. Often the results lead to a few answers but more questions. Theories are devised about the new questions. and the process may be repeated several times ... (Methods of testing the new questions are devised. Tests are performed. etc.)

Note that "tests are prepared and run" is only a few words in a long process. That includes constructing models, initializing models, validating that the models are stable both in internal testing and beta testing, and finally releasing the Project to FAH.

Eventually, the conclusions are written up in a scientific paper for peer-review. Writing/editing/reviewing those papers is another important aspect of the research, too.

The cache of new projects is somewhere in somebody's brain, but most likely the ideas are, as yet, not clearly formulated enough to turn into a research project. Moreover, in some cases the tests of the theories might not even require FAH at all.

As you noted, the projects are not held back, except if you count holding a project back from FAH which isn't likely to produce any useful science. The quality of science coming out of FAH is outstanding, as evidenced by the number of papers that are accepted by the scientific journals. http://folding.stanford.edu/English/Papers

Mitsimonsta wrote:... it misses out on addressing the elephant in the room.

Why is it that PG does not have a 'cache' of tested and approved projects which are ready to be released when there is a lack of work for any particular client?

You are mistaken. There is no shortage of SMP, GPU, and CPU work units, so there is no elephant in the room. There is only a shortage of work units from a TRIAL program. And that TRIAL program clearly stated that WU availability would NOT be guaranteed, regardless of the font color or boldness you use.

PG does have a cache of WUs, as you call it, of SMP, GPU, and CPU work units. Switch to one of those. As Bruce mentioned, not all of the science done by FAH is suitable to be run in the -bigadv format. But don't worry, for those who can run them, the new 12 core minimum -bigadv WUs should have less competition for the WUs when they become available.

Yeah, if I had a 16 thread machine I'd be more than happy with a couple of days of no -bigadv in return for a whole new class of bigadv work units!

Don't worry guys, some of us have been supporters of the project for a long time now,
and despite your best efforts so far most are still here,
looking forward to those 12 core wu's when they arrive in the Win version, all ready and waiting here...
Just don't take too long....

Please keep us posted with any ideas on when the new bigadv unitls will likely be avalailable. Is this likley to to be hours, days or a week? Keep us informed so we can Fold (the biggest thing possible) On!

At least this thread let me know what the issue is so I could reluctantly flip to -smp and not be spending time looking for other issues.

Thanks!

ElectricVehicle wrote:Please keep us posted with any ideas on when the new bigadv unitls will likely be avalailable. Is this likley to to be hours, days or a week? Keep us informed so we can Fold (the biggest thing possible) On!...

If you mean the Servers then you might have to watch the updates thread (or this one). If you mean the 12 Core bigadv WUs, then you can monitor the progress here (viewtopic.php?f=66&t=18756).

I thought the clients were designed to automatically download a regular -smp if no -bigadv WU were available? That doesn't appear to be happening.

The new bigadv units will likely move to public beta testing within 2 days. Progression from there depends on how the results look.
Regarding the assignment servers, they should automatically roll over from bigadv to normal SMP, but that functionality doesn't appear to be working properly.

Thanks Kasson and everyone else. I won't stay up tonight waiting for bigadv to return! I'll do some SMPs by re-configuring and pick up some bigbigadv when they return in a day or two. Hexamonster Hungry!!!

I also suspected that the bigadv to SMP rollover when bigadv aren't available might be controlled by the assignment servers and you just confirmed that. So it looks like there's a little problem in the new assignment servers to handle that rollover. And that explains how existing clients that used to rollover to SMP aren't doing it now, because the client requests bigadv but the assignment server decides whether to hand out bigadv or SMP when there aren't any bigadv available.

One of my machines has been waiting for the past 8 hrs or so for work.