In case you hadn't noticed, the latest batch of GetDecic WUs have much longer run times than usual (2 days on a fast host). Because of this, some users turned off this app in their preferences, in favor of the much faster GetBoundedDecics.

In the short term, we are more interested in the GetDecics results. So as an extra incentive to get users to run the GetDecics app, we are granting 50% more credits to all successful GetDecics results. This will be for a short time, until the current batch (14x121) is complete. For those who don't know how to select the app, goto your account and click "NumberFields@home preferences"; the rest should be easy.

I can't get any GetDecic tasks. Are there any available?

---

Reno, NV
Team: SETI.USA

There should be plenty available. Let me try adjusting the weights again.

Just curious, is anyone else having problems downloading WUs?

My hosts are fine, so I can't tell if there's a problem.

Just curious, is anyone else having problems downloading WUs?

My hosts are fine, so I can't tell if there's a problem.

My most recent were 11:15 UTC today - they downloaded fine.

I haven't asked for any more since then, now that I (and my machines) know how long DS-14x121 are likely to take... ;-)

Hi
Got a few GDF wu`s her to :)

But if they will finish i within deadline set , is at the time hard to tell.(got 8wus this morning,with a deadline set to 16 mars.4core Box)

Will they get paid if the go over the time limit,or get canceled by server.
How does it work on this project , concerning these issues ??

morgan

PM
GDF wu`s downloaded within regular crunching, no problem ! ;)

Good question! So as you've seen, the deadline is 7 days. What the client doesn't tell you is that the "grace period" is an additional 7 days. That means you have 7 more days after the deadline in which to return the result and still get credit for it.

Just to be safe, I would suggest aborting any task that has not started and is getting close to the deadline.

Will they get paid if the go over the time limit,or get canceled by server.
How does it work on this project , concerning these issues ??

If the task has not started running before the deadline - so no time is wasted - then the task will be aborted by the client on your computer, without reference to the project.

If the task has started - it will be allowed to continue until complete. If the time taken is really excessive, at some point it may get discarded without payment, but that won't happen for several days after the deadline. My task 796522 was due 28 Feb 2012 | 23:22:56 UTC, returned 5 Mar 2012 | 3:25:36 UTC - over 5 days late - but still validated and credited.

Don't push your luck too hard, though.

97655 NumberFields@home 3/9/2012 3:40:44 PM Requesting new tasks for CPU
97656 NumberFields@home 3/9/2012 3:40:44 PM [sched_op] CPU work request: 364269.67 seconds; 0.12 devices
97657 NumberFields@home 3/9/2012 3:40:44 PM [sched_op] ATI work request: 0.00 seconds; 0.00 devices
97658 NumberFields@home 3/9/2012 3:40:47 PM Scheduler request completed: got 0 new tasks
97659 NumberFields@home 3/9/2012 3:40:47 PM [sched_op] Server version 613
97660 NumberFields@home 3/9/2012 3:40:47 PM No tasks sent
97661 NumberFields@home 3/9/2012 3:40:47 PM No tasks are available for Get Decic Fields
97662 NumberFields@home 3/9/2012 3:40:47 PM No tasks are available for the applications you have selected.

---

Reno, NV
Team: SETI.USA

Can't get any Linux work.
Getting the same as zombie67.
I did get a couple of Windows work units but nothing for the two hosts I just attached to the project that are running Linux.

Conan

---

I think the high demand for the GetDecics app is confusing the scheduler.

I adjusted the weighting higher to 100-to-1, so it should issue 100 GetDecics for every BoundedDecic. Last time I did this there were complaints of no BoundedDecic WUs, but maybe things will be different now...

Give it another shot and see what happens.

I also found some config items that I wasn't previously aware of. One on them is the size of the job cache that the scheduler uses. I bumped this up from the default of 100 to 800 jobs. Let's hope that keeps it from running out of work.

Yay! Finally got some GetDecics tasks!

Me too! ;)

Estimated time to completion on sandy bridge is ~1 hour. I thought these ran ~2 days?

Edit: If these are really ~2 days long each, I will have a cache of 24 days per core. What's the deadline again?

---

Reno, NV
Team: SETI.USA

Me too! ;)

Estimated time to completion on sandy bridge is ~1 hour. I thought these ran ~2 days?

Edit: If these are really ~2 days long each, I will have a cache of 24 days per core. What's the deadline again?

On my 3.3GHz core i5, I have seen times between 30 and 60 hours, with the average somewhere around 48 hours. But according to the server_status page, the average of the last 100 WUs was 69 hours.

Yeah, it looks like you will probably be aborting some WUs. The deadline is 7 days with a 7 day grace period.

Yeah, the time estimation is not correct. I believe when I first started my tasks, they said something around 2 hours as well, but they are still running.

Do these tasks checkpoint? Just curious. I wouldn't want to reboot and lose a days worth of work.

Any estimate on how long you will be giving out extra credit for the GetDecics tasks?

Any estimate on how long you will be giving out extra credit for the GetDecics tasks?

well, tough stuff deserves better payment.

i think that's the deal..

The answer to your first question is, yes checkpointing occurs every 5 minutes. I haven't seen any crashes caused by the app itself (knock on wood), but every now and then some users experience an error (with the client?) that kills the thread. The error message is the same as you would get if you went to the task manager and killed the process (or used the kill command in linux). The few hosts that this happened on never complained, so I assume they were doing something to cause it and know the cause. Bottom line, you shouldn't have any problems with the app dying. But there is always that risk, and hence the extra credits.

For your 2nd question, the extra credits will continue until the current batch is finished (DS14x121). From the batch_status page you can see how many of these are left. For fairness, I will wait until all users have returned those that are still in progress. So that means you can still receive the extra credit on the next batch (DS15x???) while we wait for the previous batch to finish. At any rate, I will send out a notice before I stop the extra credit.

I'm happily crunching away. Thanks for the response.