Folding Forum

This is a question more out of curiosity than anything else. It seems like whenever my computer finishes a project it simply runs the same project with the same project id over again. For example my CPU seems to be always running project id 11293 while my gpu seems to be always running project 7903. My best guess as to why this happens is that the same project is run with slightly different parameters but I'm not sure so I thought I would try to verify my hypothesis here.

Hi there Hilariousity (LOL!) welcome to the Folding@home support forum!

Sometimes my machine does that as well. I wouldn't worry too much about that. The Stanford servers pick a project for you based on your client settings, system specs, and operating system. This question has been asked before, and IIRC the typical response was that it's just the way things were picked and assigned to you. Maybe that particular project was given a high priority so the servers picked it more often than other projects. Who knows. If everything is running fine, things are okay.

Note the project numbers might be the same, but each work unit has unique Run, Clone, Gen numbers.

And each work unit is a fractional slice of time, so the work is serial in nature.

Like 7im said, as long as the RCG numbers are different, there's nothing to worry about. It might be a bit boring to run the same WU's over and over again, but you'll get new WU's someday!

JonazzDJ wrote:It might be a bit boring to run the same WU's over and over again, but you'll get new WU's someday!

Don't you mean the same projects? Running the same WU over and over again is a problem

Hilariousity, my clients do the same. I can get 6 WUs of project 8042 in a row.

Yeah that's what I meant

My guess is that it's more efficient to download a new WU from the same server you're uploading to than to find another server with work for your machine. Why waste time disconnecting from one Work Server, connecting to the Assignment Server, and then connecting to a Work Server when you're already connected to a Work Server that's certain to have work for you. There's nothing wrong with processing another WU from the same project

bruce wrote:My guess is that it's more efficient to download a new WU from the same server you're uploading to than to find another server with work for your machine. Why waste time disconnecting from one Work Server, connecting to the Assignment Server, and then connecting to a Work Server when you're already connected to a Work Server that's certain to have work for you. There's nothing wrong with processing another WU from the same project

That's a good possibilty. Since I started using SMP via the V7 client, I haven't downloaded a single A3 influenza project. With V6, 80 % of my SMP WU's were of that kind.

bruce wrote:My guess is that it's more efficient to download a new WU from the same server you're uploading to than to find another server with work for your machine. Why waste time disconnecting from one Work Server, connecting to the Assignment Server, and then connecting to a Work Server when you're already connected to a Work Server that's certain to have work for you. There's nothing wrong with processing another WU from the same project

Sorry, but there are good scoring projects and bad scoring projects. You are describing a situation that once you get assigned a bad one, you'll get another bad one till they run out. It doesn't spread the joy between everyone evenly and I would contend that that is inherently unfair or in other words "wrong".

P5-133XL wrote:...
Sorry, but there are good scoring projects and bad scoring projects. You are describing a situation that once you get assigned a bad one, you'll get another bad one till they run out. It doesn't spread the joy between everyone evenly and I would contend that that is inherently unfair or in other words "wrong".

Which are the good ones, and which are the bad? Let's get the bad ones fixed.

Or is this a case of fixing some inflated ones that make the regular ones look bad? We should fix those also!

It's not unfair when "most" projects are neither bad nor good.

It's better to design for the operational goal of evenly performing projects than to design for the occasional glitches. (a good design would handle both equally well, but that takes a lot of resources...)

Zim, you know that there projects that are good and bad points wise. You've been around long enough and seen the complaints and seen people striving to cherry-pick. You know it is true. A perfect example are the p7640-p7644 that they just pulled back into beta.

Fixing (both the good and the bad) is good in theory, but in practice it doesn't happen nearly enough. The p7640-p7644 was pulled not because they gave poor points (and it drastically does) but because there were too many bad WU's that were not being returned. There were lots of people complaining about those projects from the start because of poor points and not using the GPU at 100%.

Just because most are neither good or bad does not make the system fair. It is that bias that ensures the the same people get the same project that makes makes it unfair. That way if you get assigned a good one then the odds are that the next one will be good too and if you get a bad one the odds are that you will get another bad one next time. Those good and bad WU's are not being evenly spread out to everyone, rather it is the same people that get them over and over again. The benefits of good WU's and the burden of bad WU's are not being distributed evenly to all is very close to the definition of unfair.

Yes, it takes more resources to give the WU's out totally randomly but really how much more. I would contend, not that much. More to the point, it would cost money to hire the programmer to correct the issue and money is a very limited resource. So inertia rules and the system remains unchanged. I understand that, but don't give me that it isn't unfair. I'd be much more impressed with admitting it is a flawed system but there aren't enough resources to be able to fix it. Honesty is really much better than trying to spin your way out.

I'm not buying the argument that unfair is really fair to the majority. Fairness is really about minorities. It is what is happening to a few that is not happening to everyone else that defines fairness.

What is happening to a few right now happens to EVERYONE over a longer time frame, not just a small minority, and not just the same minority each time. No one is being singled out, or purposely targeted, which is sort of a requirement in the definition of being unfair.

Assignments, over time, are random enough that it all averages out, and is thus fair, or at least fair enough that you really don't have much to complain about. So called good and bad projects don't last forever, and so you never get stuck on them for very long. And when good or bad projects are a very small fraction of the total sum of work, it again isn't much to complain about.

There are bigger windmills to be tilted at.

Actually it happens in long periods of time and it does not happen to everyone, it is pretty much a flag, OS, FAH version and hardware related most do not have enough hardware or play with it enough to be able to tell, but for some with enough hardware you can figure out the best combinations and keep the flow coming. Just of giggles try an i7 on v7 windows7 operating system and no flags see what you get then try it with an advanced or another flag see what you get then switch to Linux v7 linux v6 Windows v6 and play with flags or just run them all with no flags. Every combination will be different in WU assignment.

Part of the problem is either a coding error or coding choice when set up, I do not know or care either way, what I do know is it exists. I have set up rigs that will run months on end getting the same class of WU's it is fairly easy to do but takes time. Is it fair the way Stanford has set it up I can not answer that question but in appearance it seems to be out of whack at times. If there is a dud running out there the way the current assignment servers operate there will undoubtedly be a way to avoid them. While it can be manipulated it is quite a bit of work to do so, and to figure out the combinations, the avg user will not take the time to do so.

bruce wrote:My guess is that it's more efficient to download a new WU from the same server you're uploading to than to find another server with work for your machine. Why waste time disconnecting from one Work Server, connecting to the Assignment Server, and then connecting to a Work Server when you're already connected to a Work Server that's certain to have work for you. There's nothing wrong with processing another WU from the same project

That may apply with the V6 clients, but since the V7 beta client downloads WU's before ever connecting to the server to upload its completed WU, it obviously does not explain getting another from the same server. With V7 I will get streaks where my machines only get assignments from the same group of projects, then switch to another WS for a while. Or sometimes it is for a single WU from a different project group and back to the previous ones for a while.

As for "good" vs. "bad" WU's, I get some of both and a lot that fall somewhere in the middle. Just not worth worrying about most of the time. The only exception is when something goes way out of the normal range, and those are rare. There is even variation within projects. I get some WU's from a project that run at a 5:30 minute TPF, others from that same project average in the 6:30-7 minute TPF.

In the logs for both v6 and v7 there's a clear indication that the assignment server is contacted before the WS:

v7

06:05:56:WU01:FS00:0xa4:Completed 247500 out of 250000 steps (99%)
06:06:47:WU01:FS00:0xa4:Completed 250000 out of 250000 steps (100%)
06:06:48:WU01:FS00:0xa4:DynamicWrapper: Finished Work Unit: sleep=10000
06:06:48:WU00:FS00:Connecting to assign3.stanford.edu:8080
06:06:49:WU00:FS00:News: Welcome to Folding@Home
06:06:49:WU00:FS00:Assigned to work server 171.67.108.60
06:06:49:WU00:FS00:Requesting new work unit for slot 00: RUNNING smp:8 from 171.67.108.60
06:06:49:WU00:FS00:Connecting to 171.67.108.60:8080

v6

[03:28:57] + Attempting to get work packet
[03:28:57] Passkey found
[03:28:57] - Will indicate memory of 32233 MB
[03:28:57] - Connecting to assignment server
[03:28:57] Connecting to http://assign.stanford.edu:8080/
[03:28:57] Posted data.
[03:28:57] Initial: 8F80; - Successful: assigned to (128.143.231.201).
[03:28:57] + News From Folding@Home: Welcome to Folding@Home
[03:28:57] Loaded queue successfully.
[03:28:57] Sent data
[03:28:57] Connecting to http://128.143.231.201:8080/