I still have 3 running on my Win 10 64bit computer using BOINC v7.2.33.
They have each sent 3 ZIPs successfully and are at 33% progress.

The time remaining estimate looks too short though, so they are taking longer than the original estimate.

Time estimate is way to low. On my machine the estimate for unstarted tasks is 212 hours, but, it has taken 80 hours for one task to reach the 25% mark. At that rate it will take in the neighborhood of 360 hours to reach 100%.

---

Another thing about graphics (apart from detecting faulty parameters described above) is that they might help attract new crunchers to the project.

Just my humble opinion...

big uploads are probably going to be a fixture too. One of the beta tests had uploads over a 100 megs each.

Zip files of 100 MB’s is probably high. I just uploaded 2 zip files that were 69.28 and 70.08 MB's respectively.

---

FWIW my Windows 8.1 PC has started running 2 wah2 tasks, currently at ~2% and 4% completion, with ~129 and 126 hours remaining respectively. So far no failures have occurred.

The wah2 tasks seem to be progressing in line with prior tasks of similar size. IOW just the normal course of events. At the rate it's going I'd expect first trickle in ~1.5 days.

I'm keeping a good thought I'll continue to have nothing interesting to report. :)

On my PC with i7 and 64 bit Windows 7 task is going on, but very slow and continues to slow down.
This my point of view is based on hypothesis FLOPS and credits relation is correct.
So, on my machine:
HadCM3 short - all were done in average 85K sec, 600 credits for job done;
Wah2 - 3 checkpoints reached in 252K sec, 600 credits too.
It looks like the modell is going on, but with brakes, which are pressed more and more: the "speed" for 1st checkpoint was 6.8 sec/TimeStep, for 3rd - 7.2 sec/TS. So, looking forward...

---

I'm not part of the project, just another cruncher, with a few privileges...
Perhaps it will change again in the future, and perhaps not.

Les, I know You, I remember You... :-)
IMHO, it is worth to talk about to be or not to be (for graphics or some another type of "keep us informed") in a separate discussion.

---

The three WAH2 models that I have running on my i5 are going at about a third the rate of the PNW models - about 4.5s/ts compared to 1.3s/ts. 5 trickles down on 2 and 4 on the other one - all about 40% complete. Estimated time left below what has already passed!!!

Similar results for my i7 win10 64bit 7.2.33 set up.

Shorts and PNW about 1.6s/ts
AFR about 2.4s/ts
WAH2 about 5.3s/ts

Now up to 55% progress on 3 tasks, I estimate it will take around 200 hours total per task.

With always on fast broadband the file sizes are no problem.

Oops I am sorry . . . I had to edit my post to a new post :(

IMHO, different sec/TS value for different types of CPDN models is absolutely normal situation.
IMHO again, better indicator of "speed" is useful job (measured in credits) pro sec.
For example, on my PC ANZ tasks are/were 4 times faster as Wah2:
ANZ - 52 K sec between trickles, 500 credits:
Wah2 - 81 K sec, 200 credits.
Hypothesis (based on intuition only)... :-)
Wah2 algorithm is "green" or not optimized enough. Instead of "open the door, enter the house" algorithm does "at first walk 3 times around the house, then open the door..." Maybe these "walking around" operations were useful for debugging, but are useless now, code writers just forgot to remove them.

---

_




Good news :)

my longest running wah2 work unit has just now made it to 50 % progress . . .

it took 125 hours to get there,

with an estimated time remaining at 77 hours,

[edit]

and the estimated time remaining seems to be dropping fast ... now at 76.2 hours.

[/edit]

I have 39 wah2 work units still crunching.

so far so good :)

fingers crossed :)

wah2_eu2_a26l_1902_1_010151538






_

estimated time remaining seems to be dropping fast ... now at 76.2 hours.

Oops . . . I think I spoke too soon.

estimated time remaining seems to be going up ... now at 84.20 hours.

All my WAH2 tasks - including those not started - have just had the time remaining recalculated to be in line with the time taken and percentage completed. Hooray!!

Yes same here yeah :)

Mine have not. They still have a wrong estimate.

I see a new batch of WAH2s have been issued. Are these the same as before (just a re-issue), or have they been modified I wonder?

Mine have not. They still have a wrong estimate...

Is this wrong estimate affecting the processing in some way? IMHO, no...

---

I agree that it does not affect the processing of the tasks themselves.

It is however an annoyance, because it then makes all the other estimated times increase. That in turn delays the downloading of new tasks because CPDN sees that I have much more work to do, so I do not need more tasks yet.

For Example: currently, the estimate for SHORTs has gone up from 22 hours to over 27 hours. Of course, they will only take 22 hours, it is just that the estimated time is now incorrect.

That happened with the last batch of AFRs which had e..x..t..e..n..d..e..d Remaining time Estimates!

These WAH2s are behaving in a similar fashion.

And time estimate errors in one application will go on affecting all applications for the project, until CPDN can finally complete the migration to a new version of the BOINC server software which can decouple the runtime estimate smoothing of the different application versions.

But the current Runtime Estimation code is so crude that I'd hesitate to advocate its adoption here.

First two WAH2 tasks of mine completed, 146 hours vs 125 hours forecast (from a mix of 43-hour 12-month and 71-hour 18-month PNW), now converging.

No evidence of a substantial slowdown from these two: