It runs 4 tasks at the same time.

However, for what it's worth, it runs completely and directly on solar power. It only needs 15W to run, so in terms of energy efficiency, it is very good.Total computing power is not exactly great.

The tasks have been running for about 168 hours and reached about 57 %.
They might need another 7 days or so.
(Proc. atom d510, ubuntu 64 bit)

Not sure why it's doing that this time. I restarted the project just for good measure. Please let me know if it continues to behave this way, so I can look into this further.

If you double the deadline you'll wait twice as long for the first result to return but once the ball gets rolling the results come back just as quickly ....

Agree totally about the flow rate, but a long pipeline increases the number of tasks in flight. Fot some projects, that has a significant impact on the server specification - storage size requirement for both the database and workunit data files. But the data files here won't be a major problem...

May I ask, why you prefer the GetBoundedDecics app? Is it the shorter run times?

Because hourly credit is the same for both. I understand if you don't like waiting days to finish a WU, which takes even longer with an older (and slower) CPU.

Wow! Check out these run times:
http://stat.la.asu.edu/NumberFields/workunit.php?wuid=623684
http://stat.la.asu.edu/NumberFields/workunit.php?wuid=606269

I wonder who this might be...

I get 3.4 GFLOPS on my core i5-2500K @ 3.3GHz. Host 1461 gets 5.3 GFLOPS, a 56% increase. Overclocking by 56% does not seem unreasonable. And how accurate are the benchmark tests anyways?

I know I don't get the same values every time I run the benchmarks. And then there's the question of linux vs. windows (my core i5 runs windows and host 1461 runs linux); in my experience, code built on linux is faster than the exact same code built for windows - so I wouldn't be surprised if benchmarks on a linux platform beat the benchmarks on a windows platform for the exact same type of CPU.

I have a problem with my theory...

The 2 that I have/had (on VERY slow hosts) jumped to 50% very quickly and started climbing steadily.

One had got to 80-something percent and suddenly finished after around 39 hours - Got decent credit for it too, about time, I thought I was jinxed ;)

If you don't use the recommended workarounds and insist on running fossil-ware then you're never going to find joy with BOINC.

I've asked the BOINC developers to re-instate the server code DCF safeguard against over-allocations like this, but I didn't get a reply. It might help if this project (and other projects with what I've called "non-deterministic tasks" - tasks wehere the runtime can't be predicted in advance) could re-inforce the need for server code which guards against over-allocation.

Also, thumbs up to @Senilix for spotting the underlying problem :)

@Al

All of your WUs with improper (too high/too low) credit have one thing in common: all show up with a run time of 0.00 sec.

I would guess this is (part of) the problem!

... fourth is credit based on runtime (a new one implemented recently by DA for the cases where creditnew doesn't work well)."

go read the docs...

Link to doc (or other source) for #4, please? I don't recognise it.

Not sure how to "get rid of it", as it's embedded in the latest server code.