A batch of 500 WUs *_TRYP_* have been sent and will take TWICE as much to compute than normal.We are talking of 10 nanoseconds of simulation per WU! (for what most people still use big fat supercomputers). We need them for a very interesting publication we are preparing related to this experiment. Many thanks for the effort!

So will take the 10 *meta_pYEEI*.

Link dont work. Link are:http://www."http.com//www.youtube.com/watch?v=XnjmHYUvFW4%22

Maybe you mean:http://www.youtube.com/watch?v=XnjmHYUvFW4

Link dont work. Link are:http://www."http.com//www.youtube.com/watch?v=XnjmHYUvFW4%22

Maybe you mean:http://www.youtube.com/watch?v=XnjmHYUvFW4

Link dont work. Link are:http://www."http.com//www.youtube.com/watch?v=XnjmHYUvFW4%22

Maybe you mean:http://www.youtube.com/watch?v=XnjmHYUvFW4

You mean: http://www.youtube.com/watch?v=XnjmHYUvFW4

The sad thing about these work units is the 56% GPU usage (on a GTX 480)

I have one that was already 25% done when I saw this post and turned HT off, shaders turned up to 1756 (mv 1138)... bring on ALL 10 ms WUs!!!
On WinXP Pro 32 - I am now getting 68% usage.

@TAPIO - I don't see any of these new TRYP type of WUs on your machine - what kind of WU are you talking about on the 80% usage?
____________
Thanks - Steve

I've completed two new 'fatty' WUs on two different computers.
The first one finished in 9 hours 11 minutes (13.23ms/setp). (GTX 480 and C2Q 9550)
The second one finished in 9 hours 51 minutes (14.2ms/setp). (GTX 480 and C2Q 6600)
I realized how much these WUs CPU dependent. (I use the SWAN_SYNC=0 setting on both computers)
Both tasks were 2.5 millon steps.
But I don't understand how could these get the same credit as Snow Crash's 1.82 million step wu, which took only 6 hours 54 minutes (9.1ms/step). (GTX 480 and i7 920)
An i7 920 is faster than a C2Q 9550, but I think not that much. (especially the FP units almost the same fast)
I also don't understand the different GPU clock rates of Snow Crash's task. (1.59GHz, 1.40GHz, 1.74GHz, 1.40GHz, and 1.40GHz) (this computer have only one GPU, maybe the GPU clock changed while crunching this task, and restarted 4 times?)

I have one that was already 25% done when I saw this post and turned HT off, shaders turned up to 1756 (mv 1138)... bring on ALL 10 ms WUs!!!
On WinXP Pro 32 - I am now getting 68% usage.

@TAPIO - I don't see any of these new TRYP type of WUs on your machine - what kind of WU are you talking about on the 80% usage?

I like this wu:

http://img.lbzh.fr/images/capturexqx.png

it is not part of the 500 wus?
____________
(boinc since 1/04/09), Alliance Francophone
GA-P55A-UD5, i7 860 2.8 Ghz, Win 7 64 bits, 8 g DDR3 de ram, 2 To DD + 750 ext, boitier Haf 922 + 2 ventilo 120 noctua, ventirad noctua NH-U12P SE2, GTX 470 zotac amp edition, écran 25"

It's not.

ok
____________
(boinc since 1/04/09), Alliance Francophone
GA-P55A-UD5, i7 860 2.8 Ghz, Win 7 64 bits, 8 g DDR3 de ram, 2 To DD + 750 ext, boitier Haf 922 + 2 ventilo 120 noctua, ventirad noctua NH-U12P SE2, GTX 470 zotac amp edition, écran 25"

hello to all ;)

i have 3 questions atm:

1.)
why i only get applications for cuda ( 6.05 ) and my card is ready for cuda 3.1 ?
win7 x64
gtx 260


2.)
why are so lees wu´s on the server and only 2 WU´s maximum ???

3.) can you optimize the apps to more gpu usage ?

lg
Norman

If you look at the difference between your Q9550 and Q6600 you will get an idea of the importance of the CPU; 40min less on the faster CPU.

You should adjust bonus lines accordingly if you know something like this is coming. The 'sophisticated' BOINC management makes sure at times my 9800GT will get those monster WUs while the GTX 295 crunches usual WUs.

Difference: 21,239.74 vs 17,699.78 (just because I managed to swap cards somehow by snooze GPU). Otherwise probably just: 14,159.83.

I do not like to see being punished for adding more computing power to the project.
____________

OK, thank you Mark !

what is with open-cl support to bring up the ATI-power to the project ?

here is a post from timo strunk about open_cl ( developer poem@home ):

Hi everybody,

So, first of all: We will not use CUDA in our app. OpenCL can do everything CUDA can do and there's really no need to use it anymore (however that's my opinion). Apart from that we are working hard to get everything to work in Single Precision. So far our forcefields are exact in single precision with the exception of our Solvent Accessible Surface Area term, which will be deployed on the CPU for the moment. The new SASA forcefield is about 7 times faster than the old one on the CPU already though and during the next time somebody will be working to deploy it also on GPUs.

So the GPU part will be single precision and OpenCL; there's also no question whether we release first ATI or NVidia - these two releases won't be more than 1-2 days apart for sure, because the code is not different apart from optimization parameters. Personally I use the ATI Stream SDK on CPU for debugging bugs usually.

As to release dates: Well we were a bit off, when we estimated POEM++ to be done for the end of CASP, therefore at the moment we are hesitant to specify an immediate release date. The CPU part however is done and we are thinking to release it first, because it also gives already quite a speedup.

Best,
Timo

This is not 1.8M steps. It's still 2.5M steps but the last restart till it finished was of 1.8M steps. (maybe the message could be clearer).

gdf

Have all the Fatty wu's been sent out & how big are the files that get uploaded?

We are talking of 10 nanoseconds of simulation per WU

Ignasi,

It is now a few days ago and still no answer on this question.

Can you please give an exploination for this error?

Thanks!
____________
Ton (ftpd) Netherlands

gdf,

Thanks for the reply. See message 18476 from skgiven!


____________
Ton (ftpd) Netherlands

I'm curious. I'm currently crunching TRYP WU 1859786 which I got at the end of the server outage. Its info page says its's not a resend but a first-time d/l. Is this part of the original batch of 500 or a new batch?

Oh...belated congratulations on getting the servers back up again: you were missed, but I'm sure Collatz appreciated the overflow ;D
____________

Skgiven & Ignasi,

Again two WU aborted after a lot of hours processing at the same machine/card.

Can you please take a look and reply?

Thanks


____________
Ton (ftpd) Netherlands

@ftpd

The errors you are referring to do not come exclusively from WUs from the 'fatty' batch. This and this are HIVPR and only this one is a fatty WU.
Similar errors are reported in 9800 GT here.

App developers are already aware of it.

thanks

That's a funny error - it looks like a driver bug affecting GTX9800 (which is what a GTS250 is, too). What driver version do you have?

Matt

@skgiven,

At that time only gpugrid was running, gts250 can only do one job.
RNA World was running using CPU.
Later that week two other WU also were aborted. HIVPR?

Enough information?

Good luck
____________
Ton (ftpd) Netherlands

@skgiven,

Hi Kev,

I never aborted wu myself. There are never played games on this machine.
Just Outlook and Internet Explorer.
RNA no Beta-jobs. There were Linux-beta-jobs. No faillures.

Success!
____________
Ton (ftpd) Netherlands

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.

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.

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.

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.

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

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...

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

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.

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.

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.

Looks like those never used before commands are still not working.
I've just completed another *_long_* monster wu, normal 50% bonus been applied on it.

By new ones submitted this week we meant brand new long batch submissions.
Which I am about to do in the next couple of days.

First batch of 500 is out.
*IBUCH_AcPYEEIP_long*

With a 40% extra bonus.

happy crunching
i

First batch of 500 is out.
*IBUCH_AcPYEEIP_long*

With a 40% extra bonus.

happy crunching
i

We have cancelled all UNSENT WUs for the wrong batch.
We won't force cancel any running WU (only 230 running now), they should complete fine as normally. However, we discourage their continuation.

Correct ones will be issued in few hours with a new bonus for all will be now of 50%.

First batch of 500 is out.
*IBUCH_AcPYEEIP_long*

With a 40% extra bonus.

happy crunching
i

Negative.
Please discontinue any IBUCH_AcPYEEIP_long.

They will compute well but the experiment it is not correct. It is wasted computing. And we all hate that.

My fault. I appologise.