I've discovered a new type fatty WU on one of my computers called *_IBUCH_1_pYEEI_long_*. It's running for 4 hours 15 minutes and completed 55% (GTX 480 @ 800MHz, 63% GPU usage, SWAN_SYNC=0, C2Q 9550 @ 3.71GHz).
I'm a little surprised.

It's finished in 7 hours and 47 minutes.
Details here.

I had a _pYEEI_long_ back in June, and posted about it. Nobody took any notice then, either.

Only have 145KASHIF_HIVPR_no_boundxxxx types and take 3:30 hours, depending on de # of steps, some take longer, 4 hours. CPU is an C2EX9650 @ 3.5GHz.
GPU =GTX480 @ 1.4GHz.
I've seen many wingmen, if one is used, with exit status 98 (0x62)
or 1, especially on 200 series cards, but also good ones. And FERMI's errors, too, sometimes
If I up the clock on the GPU to 1.6 or higher, it gonna make an error in a GPUgrid WU, heat isn't an issue, since the mobo is not in it's case, which makes an awfull difference, cause no heatbuild up, CPU temp is 30C lower and runs at 3.5GHz, while one of my C2Q6600's, of which one is constantly on 90C. (According to a program capable of reading the mobo's sensors and CPU diodes, which came with the mobo (ASUS P5E,X38)).

---

Knight Who Says Ni N!

These are different tasks from those released in June; even different apps.
They may include some of the new subroutines being worked on (as with the GIANNI_DHFR1000), intended to increase turnover, or they might just need to get through more work, for a paper. Perhaps these are over-taxing the Fermi controller when the cards are overclocked, but they seem to work on GT200 series cards that are OC'd.

The double length is clearly just to annoy me, I have 6 GT240's.
On a high end Fermi 8h should not be an issue, even if you get two back to back you will complete the task in 16h (if running 24/7). If you don’t crunch that often reduce your cache.

These are different tasks from those released in June; even different apps.

That's great, but now they came out of the blue.

They may include some of the new subroutines being worked on (as with the GIANNI_DHFR1000), intended to increase turnover, or they might just need to get through more work, for a paper. Perhaps these are over-taxing the Fermi controller when the cards are overclocked, but they seem to work on GT200 series cards that are OC'd.

These *_IBUCH_1_pYEEI_long_* WUs not as stressing to the card as the GIANNI_DHFRs, they run at 30% lower GPU usage, therefore generating much less heat so overclocking is not an issue with those. BTW I've installed a larger cooler (Arctic Cooling Xtreme Plus + WR004 kit) on each of my GTX480s, so the larger heat dissipation of GIANNI_DHFRs is not an issue anymore, even when overclocked to 800MHz.

The double length is clearly just to annoy me, I have 6 GT240's.
On a high end Fermi 8h should not be an issue, even if you get two back to back you will complete the task in 16h (if running 24/7). If you don’t crunch that often reduce your cache.

Not just to you... I was shocked when I saw that it's been running for more than 4 hours, and it's barely completed the half of the WU. The first thing came to my mind was that my brand new coolers didn't do their job so well, and the card's been locked up. But then I saw the progress indicator is running, and it's eased my mind a little, so I could read the name of the WU :) So the "_long_" suffix was the right explanation for the long running time. I've posted about it to warn my fellow crunchers, once the crew didn't. BTW some *_IBUCH_GCY_* WUs are appearing as well, those are very long too (about 5h30m to complete on my GTX480s)

New type of long WUs been arrived: *-IBUCH_?_BCC_long_*
Processing of them is not started yet, so I don't know how long they will be.

p9-IBUCH_1_pYEEI_long_101130-2-10-RND3169_0

GeForce GTX 260/216 (Shader 1566 MHz): Runtime = 53,900.07 (~15 h), Granted credit = 23,863.26

New type of long WUs been arrived: *-IBUCH_?_BCC_long_*
Processing of them is not started yet, so I don't know how long they will be.

No problem on your foureighty.
I have the half of that: a twofourty and 1 BCC_long running.
Estimated runtime: 33 hours and 50 minutes and a 30% CPU-use.
GPU-load: 62% Fan-speed: 41% Temperature: 63C.

I had a _long_ IBUCH task on a GT240 (32h), and another aet1_IBUCH task that was also equally lengthy (33h). aet :)
This long IBUCH task took over 10h on a GTX470.

Dear all,

Appologies for not warning you. We should have done it some days ago.
The truth is that, as always, when it comes to publishing everything is for yesterday. The only way we can speed up the time-to-answer now is by extending workunit size. As we have explained many times, our WUs are little pieces of large calculations, and one depends from the previous completed one, and so on. In this chain-process WUs are queued again. By extending the length of a WU we reduce the waiting time.

We really appreciate your special effort in computing these monsters. For this, we will grant 40% BONUS in credits with the *long* WUs. We'll do it through a command we have never used that will be tested over the weekend. If successful, we will use it for ALL NEW *long* SUBMISSIONS starting NEXT WEEK. There is a batch of 1000-1500 in preparation that will benefit from it...

Thanks a lot guys,
ignasi

PD: By the way, next week Dec 10th we're presenting some unpublished (and unprecented I have to say) results (*TRYP*,*reverse_TRYP*) in London at the Brunei Gallery for the 2010 UK Young Modellers Forum.

Is there a way to tell the server not to send me any of the new fatty workunits? My 9800 GT, running nearly 24/7, can complete the normal workunits in time, but not any workunits that try to take twice as long with the same allowed time to completion. Even now, about half of the workunits it tries complete with computation errors.

No problem expected with them if you also increase the allowed time to completion in proportion to the expected length, though.

Bring em on ... I love when you guys push the limits ... I'm working on a IBUCH_RED right now!!!

---

Thanks - Steve

Remember to keep your cache level low; no point in having a task sitting waiting for half a day before it starts.

My cache level was already low enough to delay getting a new workunit to perhaps 1 hour before the last one finishes.

One of the big ones cancelled after 18 hrs on GTX295.
Little bit pitty!

Send me some more!

All wu's i downloaded were NO big-ones!

---

Ton (ftpd) Netherlands

Dear all,
...
We really appreciate your special effort in computing these monsters. For this, we will grant 40% BONUS in credits with the *long* WUs. We'll do it through a command we have never used that will be tested over the weekend. If successful, we will use it for ALL NEW *long* SUBMISSIONS starting NEXT WEEK. There is a batch of 1000-1500 in preparation that will benefit from it...

Just completed one of your test WUs - hope this is what you expected to see.

We'll do it through a command we have never used that will be tested over the weekend.

It looks like the normal 50% bonus was applied. Not sure if the never used before command will be run subsequent to the task completion. I guess this will be a manual test.

Richards task,
Claimed credit 127.270717592593,
Granted credit 190.906076388889.

We will see if these numbers change.

Remember to keep your cache level low; no point in having a task sitting waiting for half a day before it starts.

I do not understand the cache level issue. You get two WU's and that is all. One computes and one is in cache. There is no way to change that it seems to me. On WCG I have a 3 day cache. But on GPUGrid I have not seen any cache management function.

Remember to keep your cache level low; no point in having a task sitting waiting for half a day before it starts.

I do not understand the cache level issue. You get two WU's and that is all. One computes and one is in cache. There is no way to change that it seems to me. On WCG I have a 3 day cache. But on GPUGrid I have not seen any cache management function.

While you could do it here, this is a Boinc wide setting and will apply to all projects. As local settings override this you might as well just set it on Boinc Manager,
Advanced Preferences, Network Usage, Additional Work Buffer, set to 0.1days or 0.01 if you prefer.

As you can see there is no GPU tab or separate GPU cache setting on Boinc and the default cache setting of 0.50days is bad for this project.

For a high end Fermi you should still get away with a 3day cache, if the GPU is optimized for performance (Free CPU core/thread, swan_sync=0, always use GPU...); you can only have one running task (per GPU) and one queued task, no matter how many days cache you set, so if your high end Fermi finishes a task in under 10h then even the queued task will finished in 20h. So 0.5days or 9days makes no odds. You just have to consider the consequences of a 4h local Internet outage, system restarts and the effect of your use on the system.

On the other hand for an entry level GPU such as a GT240, these long tasks take around 30 to 32h, so if you have a high cache the queued task will have sat waiting to run for 32h before starting, and therefore will not finish until 64h after it was sent. So you are better off with a 0.01day cache. Ideally tasks get returned within 24h and if not then within 48h. Beyond that you are late and your efforts are of less value to the project. After about 4 days your efforts become worthless to the project and might even slow it down. After 5days you don't even get any credit. Personally I would prefer this credit cut-off was 4days, to better reflect the reality of the situation.

Remember to keep your cache level low; no point in having a task sitting waiting for half a day before it starts.

I do not understand the cache level issue. You get two WU's and that is all. One computes and one is in cache. There is no way to change that it seems to me. On WCG I have a 3 day cache. But on GPUGrid I have not seen any cache management function.

While you could do it here, this is a Boinc wide setting and will apply to all projects. As local settings override this you might as well just set it on Boinc Manager,
Advanced Preferences, Network Usage, Additional Work Buffer, set to 0.1days or 0.01 if you prefer.

As you can see there is no GPU tab or separate GPU cache setting on Boinc and the default cache setting of 0.50days is bad for this project.

For a high end Fermi you should still get away with a 3day cache, if the GPU is optimized for performance (Free CPU core/thread, swan_sync=0, always use GPU...); you can only have one running task (per GPU) and one queued task, no matter how many days cache you set, so if your high end Fermi finishes a task in under 10h then even the queued task will finished in 20h. So 0.5days or 9days makes no odds. You just have to consider the consequences of a 4h local Internet outage, system restarts and the effect of your use on the system.

On the other hand for an entry level GPU such as a GT240, these long tasks take around 30 to 32h, so if you have a high cache the queued task will have sat waiting to run for 32h before starting, and therefore will not finish until 64h after it was sent. So you are better off with a 0.01day cache. Ideally tasks get returned within 24h and if not then within 48h. Beyond that you are late and your efforts are of less value to the project. After about 4 days your efforts become worthless to the project and might even slow it down. After 5days you don't even get any credit. Personally I would prefer this credit cut-off was 4days, to better reflect the reality of the situation.

@skgiven: pls check your PM.