I get a FAX3 done in just under 45 hours on my GTX 460 and a FAX4 in 28 hours. A bit too big for my taste... No chance of a time bonus here. Until now I always got it...

There are two time bonuses; one for <24h (50%) and one for <48h (25%).

---

FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

There are two time bonuses; one for <24h (50%) and one for <48h (25%).

I'm not really bothered by all this credit/time wise. However, if this project doesn't want to lose others perfectly good crunching machines I would raise the credits massively.

On my overclocked GT460's on long wu's I used to get around 1 cobblestone for 1 second computing and now with Nathan WU's on the same cards I am only getting 1 cobblestone for 2 seconds computing.

It seem there is serious credit deflation on this project and thet isn't good for the amount of computing power your going to get and keep.

There also seems serious discrimination against machines with cards that aren't top rank. I think attitudes need to be rebalanced with requirments on this project.

None of this matters much to myself as I am more concerned that enough power is left over to run other things.

---

Radio Caroline, the world's most famous offshore pirate radio station.
Great music since April 1964. Support Radio Caroline Team -
Radio Caroline

By my point of wiev there is much bigger difference between the longest a and the shortest GPU tasks on Seti (runnig KWSN package: 2x on GPU CC1.1, 3x on GPU CC1.3 and on Fermi GPU makes me no sense to waste cycles and electricity for Seti), than in long queue on GPUGRID. On the other you side are right comparing to DistrRTgen or PG PSA manual tpsieving, which are giving great credit (5x - 8x more than NATHAN_CB1 series).

I run long tasks on a GTX 460 and have come to the conclusion that it is better for me to abort these FAX3 and FAX4 units....

The method that I use to estimate completion times is this:

((total minutes so far) / %done)/(0.6)

This gives total processing hours. I have found this to be reasonably accurate especially after the WU is about 10% done. It also seems to be a better estimate of the total time than the "time remaining" field plus current run time until, of course, the remaining time is small.

The FAX4 that I just finished gave about 28-hours using that method, and that is what it took.

---

For GPUGrid tasks, the time taken and % completed, can be used to accurately measure the total time. So your formula is sound. If after 1h a task is 10% completed, then it will take 10h to complete the task.

Don't go by the time "Remaining (estimate)". The estimate is based on previous GPUGrid tasks completed, and thus includes tasks of different length. It's not going to be exact.

For some other projects even the % complete is not accurate. These projects have task types with varying run times and the % complete should be considered as an very rough estimate. On such projects it's common to see the % complete time freeze for extended periods and often sit at 100% complete for a long time.

---

FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

The researchers stated that they will actively review task sizes. If for example they see higher failure rates they will most likely make changes to reduce runtime. In the mean time if any crunchers don't like the duration or experiences failures, crunch some of the normal tasks. While credit will be lower you will get badges for contributing to different research papers ;)

Adding to this comment from skgiven, I just want to reiterate that indeed we are evaluating many factors with respect to these long work units. Your comments/complaints are not falling on deaf ears, so keep them coming. Additionally, we are looking at ways to reduce the size of uploads for the users, thought it is not clear at this point if we will be able to do that. Please be patient with the implementation of changes/improvements.

Betting slip, nenym: Interesting to hear your analysis about how we compare to other projects and long vs short. I don't think we're interested in getting into a credit war with anyone, but you're absolutely correct that it's important for us to remain relevant.

Additionally, we are looking at ways to reduce the size of uploads for the users, thought it is not clear at this point if we will be able to do that. Please be patient with the implementation of changes/improvements.

I tried to compress one of the workunits and it compressed by a factor of ~5:1. Maybe the project is already set up to take advantage of BOINC's built in compression (http://boinc.berkeley.edu/trac/wiki/FileCompression) but I can't tell from the logs on my end.

If you're not doing any compression then it looks like there's a considerable benefit to be had.

Your comments/complaints are not falling on deaf ears, so keep them coming. Additionally, we are looking at ways to reduce the size of uploads for the users, thought it is not clear at this point if we will be able to do that. Please be patient with the implementation of changes/improvements.

Here goes my point of view:
1) The easiest way: put 4 queues of work
long (>12 h), medium (12-8), short (<8) and beta.
Everybody happy and the system prepared to new Keppler cards.
In this scenario I might choose short & medium, but anyone could decide upon their % dedication on this project and hardware.

2) The advaced way. Make a decent Job Planner.
This might consume a lot of ressources, but I see it profitable.
http://boinc.berkeley.edu/trac/wiki/SchedMatch
I can't believe that BOINC guys didn't work on this before with the huge differencies in hardware. Maybe the system is too adapted for SETI????

---

HOW TO - Full installation Ubuntu 11.10

Additionally, we are looking at ways to reduce the size of uploads for the users, thought it is not clear at this point if we will be able to do that. Please be patient with the implementation of changes/improvements.

I tried to compress one of the workunits and it compressed by a factor of ~5:1. Maybe the project is already set up to take advantage of BOINC's built in compression (http://boinc.berkeley.edu/trac/wiki/FileCompression) but I can't tell from the logs on my end.

If you're not doing any compression then it looks like there's a considerable benefit to be had.

This may also reduce or eliminate the problems that I am having in uploading finished WUs. If the completed task upload files are not compressed, this could explain why WUs only upload after multiple retries. (Please note that I am not the only GPUGRID cruncher that is experiencing this exact problem - please see this thread.) I think I can reasonably say that I have done everything from my end that is possible to resolve this problem, however, I was unsuccessful at resolving it.

I have had prior experience in uploading / downloading uncompressed files. My experience is that uncompressed files are prone to transmission error. IP will retry transmission, and if over a dubious connection like the one that I seem to have between my ISP and the GPUGRID server, retries may further exacerbate the problem.

In addition, this would cut the size of the upload files considerably, and lessen the time that it takes to transmit them.

As such, I am highly in favor of having completed WU upload files compressed.

---

Hello, i pushed my GTX 460 to the limits, full voltage, at 900 chipset clock, hopefully it wont burn up, hopefully it will fall into the first 24 hour bonus time. It will be very very close to 24 hours, my upload is at max. 45 KB/s, when it happen i will get 75.000 points on FAX4 , aren´t i ?

close, 71400 is the exact value :)

---

DSKAG Austria: http://www.dskag.at

too close , i think, the WU got crashed , i lowered the chipset clocking about 10 Mhz and will see.