I noticed that the ATM tasks are receiving 1,125,000.00 credits each. This seems several hundred times greater than what I would expect for the computation time of these tasks.

I noticed that the ATM tasks are receiving 1,125,000.00 credits each. This seems several hundred times greater than what I would expect for the computation time of these tasks.

That's because BOINC credits are calculated based on computation operations (flops) not computation time, and GPUs have much higher flops than CPUs.

That's because BOINC credits are calculated based on computation operations (flops) not computation time, and GPUs have much higher flops than CPUs.

At this project, they aren't calculated at all - they are given at a fixed rate for each application type, set by the adnins.

That's because BOINC credits are calculated based on computation operations (flops) not computation time, and GPUs have much higher flops than CPUs.

Yes, I well am aware of how BOINC credits were originally designed. That is why I am pointing out the credit issue. If I continued crunching these tasks, the credit would eclipse projects I have been crunching (with GPUs) for 12 years in a matter of days. These even seem high compared to other GPUGRID subprojects.

I had 35 ATM Work Units over the recent days and not a single error on 2 Linux machines.
Congrats to the developers, great job!

I had 35 ATM Work Units over the recent days and not a single error on 2 Linux machines.
Congrats to the developers, great job!

I too had quite a number of ATMs on my Windows machines, and almost all of them worked well - so obviusly the inital problems with Windows were fixed, which is great! Hence, also my congrats to the developers :-)

On March 4, Richard Haselgrove wrote:

The non-beta ATMs are flowing again. Hopefully I can get up to 11 completions so the server will start to recognise the true processing speed this time.

On some of my hosts I've processed clearly more than 11 completions, and still BOINC shows up to 20 days in column "remaining time"; which means that no other tasks are being downloaded (and parked in waiting position) as long as 1 task in being processed.

Interesstingly enough: on the first or even second day, the behaviour was different: a remaining time of about 8-10 hours was shown, hence more than one task per GPU could be downloaded. And then, all of a sudden, the remaining times changed to up to 20 days - no idea why ???

Usually it means you did other work like the QC tasks which reset the DCF to a higher value.

That borks the previous lower value and correct estimated times for the ATM tasks.

Usually it means you did other work like the QC tasks which reset the DCF to a higher value.

That borks the previous lower value and correct estimated times for the ATM tasks.

For me, on my Linux boot, it's the other way round. I need to set DCF to 0.01 in order to get reasonable estimates for QC tasks (still almost 10x the real duration though), but once ATM gets in the mix, the DCF skyrockets...

Anyway, Erich56 being on Windows, unlikely that QC tasks were the issue.

But I'm seeing similar results on Windows. Even though ATM tasks consistently finish faster than any original estimate, at some point they go up to an estimated time of 20+ days.

Anyway, Erich56 being on Windows, unlikely that QC tasks were the issue.

exactly

I now seem to receive several tasks which fail within 1-2 minutes.

As one can see, these tasks have been failing on hosts of other volunteers as well:
https://www.gpugrid.net/workunit.php?wuid=28095144

Why are all these faulty tasks being sent out all of a sudden?

I now seem to receive several tasks which fail within 1-2 minutes.

As one can see, these tasks have been failing on hosts of other volunteers as well:
https://www.gpugrid.net/workunit.php?wuid=28095144

Why are all these faulty tasks being sent out all of a sudden?

I have the same problem:

https://www.gpugrid.net/results.php?hostid=610674&offset=0&show_names=0&state=0&appid=41

Why are all these faulty tasks being sent out all of a sudden?

Look in the task report on this website. The first one I tried was blank, but the next said:

openmm.OpenMMException: Unknown property 'version' in node 'IntegratorParameters'

That suggests an error preparing the batch - a project problem, not yours.

Why are all these faulty tasks being sent out all of a sudden?

Look in the task report on this website. The first one I tried was blank, but the next said:

openmm.OpenMMException: Unknown property 'version' in node 'IntegratorParameters'

That suggests an error preparing the batch - a project problem, not yours.

Thank you Richard, I did spot what stderr was showing. So it was clear to me anyway that there seems to be a problem with the batch.
I keep receiving all these faulty tasks, so I'd better switch to "no new tasks"

Why are all these faulty tasks being sent out all of a sudden?

Look in the task report on this website. The first one I tried was blank, but the next said:

openmm.OpenMMException: Unknown property 'version' in node 'IntegratorParameters'

That suggests an error preparing the batch - a project problem, not yours.

all these faulty tasks are "CDK8_" - I have received about 30 of them this afternoon.
Once more I am questioning whether tasks are not being testet before a full batch is released. In case of these CDK8, a test taking no longer than a few minutes would have revealed the problem.

CDK8_s are being issued now. I have three running normally, but they're all on Linux machines. That shouldn't be a problem for an error of this type, so I would expect them to run under Windows too - but approach with caution!

Yeah, but what exactly does that have to do with getting work units processed from computers that are primarily running a Windows OS from what I can see of the folks who are contributing here?

Yeah, but what exactly does that have to do with getting work units processed from computers that are primarily running a Windows OS from what I can see of the folks who are contributing here?

this is a prime example: https://github.com/gpugrid/gpugrid/issues/1

I know this thread is about the ATM app specifically. but stuff like this is why a Windows build might not be available.

the only app at this project without a Windows version is the Quantum Chemistry GPU app (PYSCFbeta). And they basically can't even build it for Windows because the main codebase they are using for their version of the application is not offered for Windows at all. there's no build recipe for Windows.

It's a misconception if you think that the applications here are 100% homegrown and original. They are using a lot of other code and applications pieced together and adapted in a custom way to do their specific work. since a major part of their code that they didn't write or maintain isn't available for Windows kind of forces their hand. it's not that they don't want to support Windows, it's either don't do the work at all, or be stuck with Linux-only but at least get some work done, they chose the latter.

to be more on-topic with this thread. ATM tasks DO have a Windows version available. some systems produce errors though for some unknown reason, while others work fine. not getting work at all is a problem with your configuration somehow since other windows systems are getting work just fine.

---

I have two windows computers running GPU GRD and I'm lucky to get two ATM work units every couple of days, no matter how often I manually request tasks.

Also, my RTX 4090 card can plow through a work unit in a few hours yet the estimated remaining time begins at over 30 "days." Since my settings ask for 2 days' worth of work, maybe there is something in that miscalculation that is preventing me from getting consistent tasks?

Once you've validated 11 ATM tasks, the DCF for that application should come down and the estimated times to completion should come down to something reasonable.

I have a watch script running and I don't think I really need it as I get a new task on the same scheduler connection I return one on.

But that is for the 65K available QC tasks. You have to wait for Windows compatible ATM tasks to appear again.