That's what I've been saying. Nothing lines up for a definitive answer. After checking my GPUgrid project stats my RAC has dropped 4000-5000 points. This started around 11 Dec and that was about the time all these DCF and no work issues started.

I have a couple of weeks off so I'm going to try and find the correlation and determine what WU get what credit and for how long they take to get processed, unless someone knows already?

As well all of my WU's are processed with ACEMD 6.55 with 3+2, no gaming. It seems that even though WU's need 0.03 CPU's they tend to finish faster with one CPU for both of them.

Pat

Nothing lines up for a definitive answer.

"Nothing" is a bit too harsh. In my case and in Xaaks example the 3232 credit WUs and the 2436 ones do line up. It just the 1888-ones that are off in both cases.

I suppose it's a simple error or maybe something doesn't scale as expected with model complexity.

After checking my GPUgrid project stats my RAC has dropped 4000-5000 points. This started around 11 Dec and that was about the time all these DCF and no work issues started.

The credit change was intended and the change to flop-based scheduling / work distribution was necessary. What was not intended and what is causing the current issues is apparently some bug in the new work distribution. It's unrelated to the credit / model change and they're working on it.

It seems that even though WU's need 0.03 CPU's they tend to finish faster with one CPU for both of them.

I don't think there have been any dramatic code changes, which reduce CPU usage under windows, so a dedicated CPU core is still the way to guarantee maximum GPU performance.

MrS

---

Scanning for our furry friends since Jan 2002

"Nothing" is a bit too harsh. In my case and in Xaaks example the 3232 credit WUs and the 2436 ones do line up. It just the 1888-ones that are off in both cases.

Ok, ok. Nothing was a bit too harsh, but here is what I have found. There are two kinds of WU's, 500 step ones and 850 step ones.

Any WU that has "GPUTEST" in the name will get full credit 3232.06. (850 steps)

Any WU that has "SH2_US_..." in the name will get 2435.94 credit. (500 steps)

Whilst any WU with "SH2_USPME_..." gets 1887.96 credit. (500 steps as well)

When I total my elapsed time for my 8800GT rig for one days worth of return, I find that my 2 GPU's were working 47.18549 hours, so just under 24hrs each.

When I total my 2 280's, I get 27.95813 hours. Just over thirteen hours a piece, which would explain the 4000-5000 RAC drop.

My 8800GT's with client 6.4.5 seems to be working ok (knock on wood) and more efficiently that my 280 rig which is running client 6.5.0 and need consistent updating.

I will post anythink new if it jumps out at me.

Pat

Yes, the drop in RAC should mainly be due to idle GPUs and to a lesser extent due to WUs with less credit per time. The out-of-work issue has hopefully been fixed by now (see new thread by GDF) ... so let's see how things work out :)

MrS

---

Scanning for our furry friends since Jan 2002

Lets see in 24hrs or so!

Cheers

Pat

"Nothing" is a bit too harsh. In my case and in Xaaks example the 3232 credit WUs and the 2436 ones do line up. It just the 1888-ones that are off in both cases.

Ok, ok. Nothing was a bit too harsh, but here is what I have found. There are two kinds of WU's, 500 step ones and 850 step ones.

Any WU that has "GPUTEST" in the name will get full credit 3232.06. (850 steps)

Any WU that has "SH2_US_..." in the name will get 2435.94 credit. (500 steps)

Whilst any WU with "SH2_USPME_..." gets 1887.96 credit. (500 steps as well)

When I total my elapsed time for my 8800GT rig for one days worth of return, I find that my 2 GPU's were working 47.18549 hours, so just under 24hrs each.

When I total my 2 280's, I get 27.95813 hours. Just over thirteen hours a piece, which would explain the 4000-5000 RAC drop.

My 8800GT's with client 6.4.5 seems to be working ok (knock on wood) and more efficiently that my 280 rig which is running client 6.5.0 and need consistent updating.

I will post anythink new if it jumps out at me.

Pat

Ok, something else I have noted.

Even though 500 step WU should be faster they are not. On average it took 14-15hrs to process a 850 step WU, for 3232 credit, on each of my 8800GT's before Dec 11. Now I get 500 step WU for 2435 credit and they are still taking 11-12hrs a WU. And finally the 1887 credit WU's take a little longer, 12-13hrs.

My 280's are the same. 5hrs to do a 500 step 1887 credit WU, 4.5-6hrs to do a 500 step 2435 credit WU and any where from 6.5-11hrs (average about 7.5hrs) to complete a 850 step 3232 credit WU.

Observation: In most cases the variance is about 1/5th the time but losing 1/3rd the credit, except in the 1887/500 step WU where the computer processes the same amount as a 2435 credit WU, in time but gets a 1/3rd less credit, again 1887.

Again just observations. I don't believe that there is such a difference in elapse time that there should be three sizes of WU's. Two, yes. A full size WU and a short WU, with credits 3232 and 2435 respecively.

My two cents.

Pat

Ok, something else I have noted.

Actually, it's the same.. just using hours instead of seconds ;)

Even though 500 step WU should be faster they are not. On average it took 14-15hrs to process a 850 step WU, for 3232 credit, on each of my 8800GT's before Dec 11. Now I get 500 step WU for 2435 credit and they are still taking 11-12hrs a WU. And finally the 1887 credit WU's take a little longer, 12-13hrs.

11-12 h is not faster than 14-15 h?

14/11*2436 = 3100, which is almost 3232. Depending on the precise values (in seconds) which you choose you can get an even better fit. That's what I meant by "In my case and in Xaaks example the 3232 credit WUs and the 2436 ones do line up."
And, yes, the 1888 credit WUs are still off.

I don't believe that there is such a difference in elapse time that there should be three sizes of WU's

I suspect the 1888-WUs are not supposed to take that long. Maybe under Linux they're faster?

MrS

---

Scanning for our furry friends since Jan 2002

Just a correction in my math: millesecond verses second.

Those would now be 500,000 step WU and 850,000 step WU.

Doh!!

Pat

Correct!

MrS

---

Scanning for our furry friends since Jan 2002

This should not be the case. If it is there is an mistake.
The credit system has not changed it is just that now we have several different molecular structures on going with more or less atoms, for more or less iterations.

It should produce approximately the same credit/day irrespective of the type of WU on the same PC.

gdf

The credit/day is definitely much lower for the 1,887 credit WUs. I've looked at the elapsed times from my machine and many others on the stats pages. The 1887 credit WUs take on average the same amount of time to complete as the 2435 credit WUs. The 2435 credit WUs and the 3232 credit WUs seem to line up pretty well credit/day wise on the machines I've observed.

Same here. Please discontinue the work units that send out 1888 credits, unless there is a fix for it. These work units take as long as the 24xx units or longer and give less credit! All (3) machines are Windows, 1 64 bit Vista &3 32 bit XP. All 3 boxes reflect the same reults. 1 machine has a 260 GTX 192 (Win XP 32 bit), 1 machine (2) 260 GTX 216 (Win XP 32 bit), & 1 machine (2) 280 GTX Vista 64 bit ( User ID 9485). Thanks for all of your hard work to make this happen!!!

Hi,

were any changes introduced to the 500k steps workunit which give 1888 credits?

I finished my third one of this kind this morning and it definitely had a shorter running time than the first two. The time per step is now in the same range as with the 500k steps / 2436 cr. units and 850k steps / 3232 cr. units.

Here are those three workunits with 1888 credits:

resultid=168029
resultid=168037
resultid=175524

The only major change on my side is a version change from BM 6.4.5 back to 6.3.21 (due to the silly behaviour of the resource scheduling for cpu-bound tasks with 6.4.5). If nothing was changed with the workunits, could this be the reason?

Regards
Alex

I have also some with same runtime but credits are lower now?!

I have also some with same runtime but credits are lower now?!

It's probably a 1888 credit WU? If so I'd kindly redirect you to my previous posts in this thread.

MrS

---

Scanning for our furry friends since Jan 2002

Change in credits? New acemd WUs taking longer than before and receiving 2932 credits instead of 3232. New credit policy?

Change in credits? New acemd WUs taking longer than before and receiving 2932 credits instead of 3232. New credit policy?

It's the old Bait & Switch Tactic, Suck um in with High Credit & then Cut the leg's out from under them & see how many hang around ... ;)

The Credits are still good but nothing like they were, I even added more Box's & my RAC is still dropping so there's been a serious reduction in Credit. When you get 3232 for a 20,000 Sec Wu & then only get 1888 for a 17,000+ Sec Wu something just don't Compute.

I hardly ever see a 3232 Wu anymore, their mostly 1888 with a few 2435 Wu's thrown in. Pretty soon you'll have to run a Dozen 280's to even hit 50,000 a day RAC ... 0_o

The new workunits use a more advanced algorithm for handling the electrostatic called PME. This new algorithm is very important for us.
However, as it is more complicated and uses libraries like cufft, the number of flops are only approximated because it is difficult to estimate them exactly. We are currently trying to work out a better estimate for the flops and further optimize the application.

There should be new apps out in the first 10 days of January.

GDF

The new workunits use a more advanced algorithm for handling the electrostatic called PME. This new algorithm is very important for us.
However, as it is more complicated and uses libraries like cufft, the number of flops are only approximated because it is difficult to estimate them exactly. We are currently trying to work out a better estimate for the flops and further optimize the application.

There should be new apps out in the first 10 days of January.

GDF

Way cool!

So I got my GTX280 just in time .... :)

While I have your attention, is there a way without destroying your schemes to tag the tasks with a hint of the number of iterations (not what you call them I know, and LHC is the one with the turns, but, a hint of the time length would be friendly).

The reason for the request is so that we can tell if the task is "rogue" and running too long. Then the participant can call for help and make an informed decision if they want to shoot the task or not ...

Our WUs are all supposed to require approximately half day on a 8800GT (114 shaders), around 6 hours for a 280GTX. For a bigger system, we reduce the number of iterations to meet this target or we increase it for bigger systems. This is not exact of course, allow for up to 50% error.

Something more, the time estimate of the boinc client is usually wrong, but the progress bar is EXACT. It's the application to tell the client how much it completed. You can do very accurate estimates from that.

gdf

One kind of WU, one level of granted credit. No matter what the WU is supposed to do. If it is a more advanced algorithm, then why are the credits lower? "It's based on FLOPS!" That great. I have seen no proof of that. It seem to be based on the number of steps in a WU. All WU's were 850k step WU's before Dec 10th and all got 3232.06 credit. Now we have 4 different WU's with all different credit, and don't reflect the lenght of time it actually took to process a WU. There is no reason that there cannot be 1 type of WU based on the 8800GT efficiency and leave it at that.

"For bigger systems we increase the iterations". That's funny because 7 out of the last 13 WU's done on this host: 16824 were the smallest WU. Not very efficient when those small 1887 WU take almost the same amount of time as the 2435 WU.

The time estimate is a hit and miss. All WU that have JAN2 in the title actually reflect the proper duration. (i.e. 5-6 hrs on a GTX280 and 11-12 hrs on a 8800GT) The previous WU never showed the proper duration just the proper elapsed time on the GPU. So I'm looking for more of the JAN2 WU's.

Pat