Folding Forum

So far I have been assigned 5 WUs for 4513 and 1 WU for 4514. These WUs' don't show up in the WU database that FAHSpy uses, nor do they show up in the server stats as of 4/21/2008. I also notice that they are not worth many points, and the points credited are not whole points, ie. they have a decimal component to them. When I go to the stats page, I notice that the number of points processed are in whole numbers. My question has to do with the decimal component of the amount of credit per WU. Do you truncate the value and handle as an integer, or do you handle the decimal component of the credit and not display it. I should be showing xxx.7 WUs at this time, or have I been cheated out of the 2.7 points that these WU's would credited by using integer math instead of decimal math?

John W. Swain

The WUs are so small, they all get completed very quickly, and then don't show on Psummary. Psummary is updated dynamially, and only shows projects that have WUs pending to send out.

Also, you get full decimal credit. The stats pages simply round off. I did a search, and the DB does show the decimal.

Points, Date, WU.

4.5 - 2008-04-22 06:12:15 - P4513 R65 C38 G9

The Pande Group is aware of the missing entries in psummary and will fix it at some point. (Soon, I hope.)

I have received and processed 10 of these. I have two in progress right now, making a total of 12. What bothers me is that they don't get credit or seem to get credit in the same order as they occur on the Extreme Overclocking Overall Rank report as well as the Stats database @ Stanford.

I also can't believe that the servers at Stanford are throwing these at my more powerful (2.8GHz) computer and sending more difficult "stuff" to my less powerful (2.0GHz) computer. Sure wish I knew how to remedy that.

To get things back in balance on my records I am going to have to shut down one of my dual core computers (the 2.8GHz one) until this resolves. My records are all messed up. I was hoping for a good week. That looks like it is out the window for now.

WU size is not indicative of importance or scientific value.

What do you think is the best way to get a large amount of feedback done very quickly? Send out a lot of small WUs to a lot of people.

stanmc wrote:I also can't believe that the servers at Stanford are throwing these at my more powerful (2.8GHz) computer and sending more difficult "stuff" to my less powerful (2.0GHz) computer. Sure wish I knew how to remedy that.

The assignment logic of the Stanford servers takes your RAM size, your OS type, any special settings (e.g.-BIgWU or -adv) into account, but its primary duty is to make sure you find a server that is operational and has WUs to give out. The "more powerful" vs. "less powerful" isn't really considered except in unusual circumstances. (In fact, 2.0 and 2.8 would probably both fall into the same category anyway.) Additional server logic such as you're suggesting is being added very, very gradually and there will be improvements in this area. At the present time, when there are several choices of project that would all work on your hardware, the final choice is often based on scientific priority and, to some degree, a random choice.

7im wrote:WU size is not indicative of importance or scientific value.

What do you think is the best way to get a large amount of feedback done very quickly? Send out a lot of small WUs to a lot of people.

The question of the indicativeness of importance relative to whom? To me it messes up my records when the system sends me work that completes quickly without proper point values being available for my records and then watching the servers report them out of order to Extreme Overclocking and Stanford stats. I have my log time stamps and the clocks are running consistently within a few seconds of each other. I think I have solved this by shutting down the faster computer and waiting until the reports catch up. As for the best way to get a large amount of feedback done very quickly, it is probably not really one of the more important determinants in the structure of the work units. I'm sure they are more likely sized or constructed on the need of studying each protein and its folding.

bruce wrote:

stanmc wrote:I also can't believe that the servers at Stanford are throwing these at my more powerful (2.8GHz) computer and sending more difficult "stuff" to my less powerful (2.0GHz) computer. Sure wish I knew how to remedy that.

The assignment logic of the Stanford servers takes your RAM size, your OS type, any special settings (e.g.-BIgWU or -adv) into account, but its primary duty is to make sure you find a server that is operational and has WUs to give out. The "more powerful" vs. "less powerful" isn't really considered except in unusual circumstances. (In fact, 2.0 and 2.8 would probably both fall into the same category anyway.) Additional server logic such as you're suggesting is being added very, very gradually and there will be improvements in this area. At the present time, when there are several choices of project that would all work on your hardware, the final choice is often based on scientific priority and, to some degree, a random choice.

I understand that, I think, but the system consistently sends to my 2.0GHz AMD X2 running linux with 1GB ram the larger more complicated work units. My 2.8GHz AMD X2 running linux with 2GB ram has consistently gotten the smaller projects. The first computer has been folding for two years. The second computer has been foldiing since last August. I do not have BigWU specified. I found a reference to bigpackets=big in the wiki and that is what is in my client.cfg . I will look up the BigWU parameter. Thanks for the reply.

If you run the clients with the default settings, the work servers are able to do a better job matching work units to your hardware. However, when you start overriding the default settings with the client configuration and client switches, then you will most often get work units designed for those specific settings, not designed for your specific hardware.

stanmc wrote:. . . but the system consistently sends to my 2.0GHz AMD X2 running linux with 1GB ram the larger more complicated work units. My 2.8GHz AMD X2 running linux with 2GB ram has consistently gotten the smaller projects. The first computer has been folding for two years. The second computer has been foldiing since last August. I do not have BigWU specified. I found a reference to bigpackets=big in the wiki and that is what is in my client.cfg . I will look up the BigWU parameter. Thanks for the reply.

There have been other reports like yours with the word "consistently" in them. As 7im says, if there are variations in your settings between those machines, that can easily explain it. If they're absolutely identical, then I don't have an explanation.

stanmc wrote:I found a reference to bigpackets=big in the wiki and that is what is in my client.cfg . I will look up the BigWU parameter.

bigpackets=big is what Folders call BigWU. They the same critter. If your faster computer has this in its client.cfg, you're good. Do note that BigWU is an indication that you're willing to fold WUs with big requirements (memory/nw transfers/both). If there are no BigWUs available OR if FAH needs a normal project to be finished early, you will get normal WUs.

Points might need to be re- calculated for the 45xx series. It looks like the benchmark amount was divided by 1.5X rather than multiplied by 1.5x. This applies to all of the 45xx series as well as this latest release.
Thank You.

Are these not the WUs which Professor Pande said would get 1.5X bonus?

anandhanju wrote:

stanmc wrote:I found a reference to bigpackets=big in the wiki and that is what is in my client.cfg . I will look up the BigWU parameter.

bigpackets=big is what Folders call BigWU. They the same critter. If your faster computer has this in its client.cfg, you're good. Do note that BigWU is an indication that you're willing to fold WUs with big requirements (memory/nw transfers/both). If there are no BigWUs available OR if FAH needs a normal project to be finished early, you will get normal WUs.

Thanks for your reply. In my slower computer with version 5.04 the bigpackets=yes with no reference to the amount of RAM/memory (the computer has 1 GB). In the faster computer with the 6.02 version of FAH the bigpackets=big and the memory is specified as 2048. I'll stop worrying about big WUs for the powerful computer and just let it compute as FAH sees fit to allow. Also, thanks to all the others who replied with suggestions or observations.

There are *no* projects with bonuses yet. Projects 4500-4515 do NOT have the bonus.
Projects 4516 onward will have the bonus. I will let everybody know via the forum when this happens. Perhaps in the next week. I'm sorry if this has caused any confusion.
--Vince
(p.s. I'm still scrambling to fix the psummary.html scripts too. Probably late tonight.)

Thanks for extra- quick response, Vince.

Points are still light, though... could be a factor if donors start removing -advmethods flag.
No hurry, when you get around to it.

Your hard work is greatly appreciated.