I'm continuing the graphic app problem here ...

nanoprobe,

We haven't seen any work unit issues to this point. I checked your results and for one of them there was another machine that had returned a successful result. For the other one there haven't been any results back yet but I will keep an eye on the results to make sure others come back successful.

There are six other hosts with the same exit code as yours however they have similar errors across multiple projects. Have you run a hardware test against the memory lately?

Thanks,
armstrdj

I had 2 ARP betas that ran for 5 days. On one that I tried restarting, it reset to 4 days and I lost a day of processing. The wingman had similar run time. It would seem that more frequent break-pointing is needed.

Cheers

Ah, the initial beta announcement didn't say, did it? I remember the software ensuring that there was enough space, but I'm not sure I remember the numbers exactly. I think it was at least 1GB/WU, and may have been a little higher.

Did anyone make a note of it?

Edit: Let me clarify that. The announcement did give the size of each WU in terms of the disk space needed to store the input and output files, but it did not say how much working space was needed to actually run them. This being a beta test, we only get given a maximum of one WU per thread. The size I gave was therefore the size I think was required per active thread. IIRC, it did go up and down because of compression, but if they are all are at the same point at the same time ...

It's an unfortunate side-effect of the way Beta tasks are issued that large tasks will get sent to machines that wouldn't be expected to run them as production tasks. This project is one of them, and you only need to think back as far as CEP2 for another one... Furthermore, I'd be extremely surprised if the other climate projects don't result in similar performance if/when they hit Beta...

I would hope that when this project goes live it will have similar warnings about the type of systems needed to run the tasks within reasonable times (along with a recommendation to use LAIM to help counter the restart issue.) And I think it will need an explicit opt-in to the project, so no "automatic opt in" when it goes live...

[Edit for completeness -- I had remembered aright (though I left out "to the" in the paragraph above, possibly confusing my point -- oops!) - see up-thread and the armstrdj reply to this post made before I got back to add the link!]

As regards execution times for this application -- I'm currently running machines with Kaby Lake processors and at least 2GB RAM per core, and my machines get through these tasks in long but not unreasonable times -- they seem to take about 20% longer than the longest-running HST1 tasks in each case.

My slowest machine (clocked at 2.8GHz) gets through one of these in under 13 hours, as does my main workstation (clocked at 4GHz but hyperthreaded and running LOTS of other stuff at the same time...); my small server box (clocked at 3.5GHz but not hyperthreaded) runs them in around 9.5 to 10.5 hours). If I think back to some of my now-decommissioned machines I suspect the i3-2100 would've taken over 24 hours for one of these, and I wouldn't even have considered running this on my ancient MacBook Pro (which would've taken 3 or 4 days, I suspect)!

One thing I can say for sure though is that despite the apparent size of the calculations being performed, these don't seem to reduce overall machine throughput in the way MIP1 does

Cheers - Al.