Project 2669?

[excelblue]

So, I've decided to start folding again after taking a 2yr haitus due to various hardware and internet connectivity issues.

In the past, I folded on pretty awful hardware and slowly earned the points. However, this time around, my hardware is a lot better (still far from ideal, though), and I'm running the beta SMP client with advmethods.

The good news is, I'm getting 1500 PPD on my laptop that I turn off on a regular basis, and that's only drawing 25W while acting as a small heater for my room.

However, I'm a bit weirded out by how I've gotten five consequetive P2669. They seem to have a very short deadline at 3 days while providing a huge amount of points (1920 / WU).

The project description tends to be a bit lacking, so I'm wondering if I may have some more insights to this.

- Why is the deadline so short? Is this some ultra-urgent project?
- Why am I getting so many of these? Same reason, lack of clients?

[Zagen30]

All SMP WUs have short deadlines, especially the ones that run on the a2 core (only run in Linux/OXS), at least compared to the uniprocessor client. They're can't be that urgent, inasmuch as any F@h project is not urgent, as evidenced by the fact that they've been around for at least a year (when I started Linux folding) and were probably been around a while before that (didn't pay much attention to the a2 WUs before Linux). Almost all the a2 projects are worth 1920 points, with the outliers earning even more; it's just the way the Pande Group benchmarked SMP WUs. SMP allows the Pande group to do more advanced simulations (I think) than a bunch of uniprocessor clients, so they reward that extra work with more points than if you ran as many uniproc clients as you have cores.

Both of the high-performance clients (SMP and GPU) have relatively short deadlines because they take advantage of advanced hardware, and the Pande Group can reasonably assume that they will be returned sooner. Since the deadlines are primarily to catch any lost WUs, they can assume that a WU is lost much sooner since they should finish a WU much sooner.

As to why you're getting so many 2669's...random luck. I've gotten a fair number of them as well, although I've been running the Linux client long enough that I've probably gotten several WUs from all the a2 projects.

[Mactin]

p2669's represent 55% of my a2's in the past 30 days.
getting 5 in a row does not seem that irregular.

[bruce]

All SMP WUs have short deadlines, especially the ones that run on the a2 core (only run in Linux/OXS), at least compared to the uniprocessor client. They're can't be that urgent, inasmuch as any F@h project is not urgent, as evidenced by the fact that they've been around for at least a year (when I started Linux folding) and were probably been around a while before that (didn't pay much attention to the a2 WUs before Linux). Almost all the a2 projects are worth 1920 points, with the outliers earning even more; it's just the way the Pande Group benchmarked SMP WUs. SMP allows the Pande group to do more advanced simulations (I think) than a bunch of uniprocessor clients, so they reward that extra work with more points than if you ran as many uniproc clients as you have cores.

Apparently you have not paid much attention to the Pande Group's explanations of urgency.

Many of the WUs in a project must be run sequentially. A series of Gens is called a trajectory, and it is impossible to run Gen 196 of a Project-Run-Clone until somebody returns Gen 195 of that Project-Run-Clone. With a deadline of 3 days, let's take a wild guess and assume that the average time between when a server issues Gen N, the WU is processed and returned, and the server generates Gen (N+1) is about 2 days. I see at least one Run-Clone that has completed Gen 196. That means that to get to Gen 196, that trajectory has required 12.8 months to get this far along.

Is it reasonable to assume that the average time is 2 days? Probably not. Consider that every delay is cumulative and that a certain number of WUs are not returned by the deadline so they get reissued with a new 3-day deadline. I'm willing to bet that my guess was too optimistic. Nevertheless, if the science requires this many Gens, then the total time to run the project is a large sum of short, urgent steps.

I don't know how many Gens will be requried to complete this project, but you cannot assume that just because a project takes more than a year to complete, that each step along the way isn't urgent -- it just that the project requires a lot of computation.

[Zagen30]

Er, sorry about that. I know that turnaround time on individual WUs is important, I know about how each Gen produces the next Gen in that trajectory, etc. How would one define the urgency of a particular project, if not by how long it's been going?

[EvilAlchemist]

How would one define the urgency of a particular project, if not by how long it's been going?

I would look at the deadline for each WU to determine the importance of the Work Unit to that particular project.

Project 2669 for example has been going for a year, but may be very important to the Pande Group.

The fact is they don't really state the "urgency" of each project.

We ,as a group, can only guess that shorter deadlines mean "needed quickly"

Otherwise, they would allow any CPU to run *any* work units but extending the deadlines.

By making the deadline short, they keep users from running them on lower hardware via no points awarded.

[Zagen30]

I would bring up some rebutting points, but I don't feel it'll get anywhere useful and this topic has already gone somewhat off-topic. I'll just reiterate that I fully understand and agree with PG's desire to get back WUs ASAP.

[toTOW]

I guess it's time to read this article again : Why fast WU return >>> volume of WU returns

[Zagen30]

Urgh. I just spent 20 minutes typing a reply only to decide to actually re-read the gumball analogy and then realized that it did, in fact, cover the assignment server weighting and such, which I for some reason failed to consider when writing my first post in this thread.