I've had three failed tasks over the last two days, but all the others have run normally. All the failed tasks had PABLO_V3_p27_sj403_IDP in their name.

But I'm currently uploading e10s21_e4s18p1f211-PABLO_V3_p27_sj403_IDP-0-2-RND5679_0 - which fits that name pattern, but has run normally. By the time you read this, it will probably have reported and you can read the outcome for yourselves. If it's valid, I think you can assume that Pablo has found the problem and corrected it.

Yes, part of the PABLO_V3_p27_sj403_ID series seems to be erronious.
Within the past few days, some of them worked well here. But others don't, as can be seen.
The server status page shows an error rate of 56.37% for them. Which is high, isn't it?

I'll switch off my aircond over night and will try to download the next task tomorrow morning.

The bad thing is that once a host has more than 2 or 3 such faulty tasks in a row, the host is considered as unreliable and will no longer receive tasks for the next 24 hours.
So the host is penalized for something which is not in the responsibility of the host.

If you are so unhappy running the available Windows tasks, just stop getting any work. Problem solved. You are happy now.

I don't have any issues with the project and I haven't had any normal work since February when the Linux app was decommissioned.

I trust Toni will eventually figure out the new wrapper apps and we will get work again. Don't PANIC!

The question isn't whether or not I am unhappy. The question rather is what makes sense and what doesn't.
Don't you think the only real solution to the problem would logically be to simply withdraw the remaining tasks of this faulty series from the download queue?
Or can you explain the rationale for leaving them in the download queue?
In a few more weeks, when all these tasks will be used up, the error rate will be 100%. How does this serve the project?

As I explained before: once a host happens to download such a faulty task 2 or 3 times in a row, this host is blocked for 24 hours. So, what sense does this then make?

So far as I can tell from my account pages, my machines are processing GPUGrid tasks just fine and at the normal rate.

It's just one sub-type which is failing, and it's only wasting a few seconds when it does so. For some people on metered internet connections, there might be an additional cost, but I think it's unlikely that many people are running a high-bandwidth project that way.

The rationale for letting them time out naturally? It saves staff time, better spent doing the analysis and debugging behind the scenes. Let them get on with that, and I'm sure the research will be re-run when they find and solve the problem.

I'll be skipping GPUGrid tasks from now on until it is resolved, as it is wasting CPU/GPU time that i can use for other projects on the machine. I'll refer back to these forums to check on updates though so i know when to restart GPUGRID tasks.

I'll be skipping GPUGrid tasks from now on until it is resolved, as it is wasting CPU/GPU time that i can use for other projects on the machine.

The 3 recent errors wasted 17 seconds on your host in the past 4 days, so there's no reason for panicking. (even though your host didn't received work for 3 days.)

I'll refer back to these forums to check on updates though so i know when to restart GPUGRID tasks.

The project is running fine beside this one bad batch, so you can do it right away.

The number of resends may increase as this bad batch runs out, that may cause a host to be "blacklisted" for 24 hours, but it needs many failing workunits in a row (so it is unlikely to happen, as the maximal number of daily workunits get reduced by 1 after an error).
The max number of "Long runs (8-12 hours on fastest card) 9.22 windows_intelx86 (cuda80)" app for your host is currently 28, so this host should be extremely unlucky to receive 28 bad workunits in a row to get "banned" for 24 hours.

On your advice i'll restart the GPUGrid task seeking, and hopefully the toin cosses go in my way and it'll fetch a wide spread of tasks to not get itself blacklisted. Interesting it is set to store up to 28, given it only ever stores 4, and that is if 2 are running active on the GPUs with 2 spare. But I guess that is down to the limits on the future work storage settings for BOINC.

There are two more 'bad' batches at the moment in the 'long' queue:PABLO_V4_UCB_p27_isolated_005_salt_ID
PABLO_V4_UCB_p27_sj403_short_005_salt_ID
Don't be surprised if the tasks from these two batches fail on your host after a couple of seconds - there's nothing wrong with your host.
The safety check of these batches is too sensitive, so it thinks that "the simulation became unstable" while it's probably not.

I changed the date to before the license expired, right after the WU started crunching and before it crashes, and then change it back. It's actually tricky to do, because boinc acts strangely when the date is moved back. My two other attempts failed, so I had enough of this.

BTW, the video card that I used was a gtx 980 ti, not the rtx 2080 ti.

I changed the date to before the license expired, right after the WU started crunching and before it crashes, and then change it back. It's actually tricky to do, because boinc acts strangely when the date is moved back.

so it's clear that the license has expired.

Changing the date of the host can indeed be tricky, even more if also other BOINC projects are running which could be totally confused by doing this. Happened to me last time when the license expired, it all ended up in a total mess.

Let's hope that it won't take too long until there is a new acemd with a valid license.

I changed the date to before the license expired, right after the WU started crunching and before it crashes, and then change it back. It's actually tricky to do, because boinc acts strangely when the date is moved back.

so it's clear that the license has expired.

Changing the date of the host can indeed be tricky, even more if also other BOINC projects are running which could be totally confused by doing this. Happened to me last time when the license expired, it all ended up in a total mess.

Let's hope that it won't take too long until there is a new acemd with a valid license.

I thought one of the reasons for the new app was to not need the license that keeps expiring. Plus Turing support in a BOINC wrapper to separate the science part from the BOINC part.

I've seen some mentions of tasks still completing properly on some rather old versions of Windows, such as Windows XP. Could some people with at least one computer with such a version give more details?

Perhaps the older versions don't include an expiration check, and therefore have to assume that it is not expired.

However, for XP, a differnt acemd.exe is used (running with CUDA 65), the license for which seems to expire at a later date. No idea at what date exactly, it could be tomorrow, or in a week, or next month ...

But the errors continue, 2 seconds into a Pablo unit and poof they error out

mikey, the tasks with errors were run on a Turing based card (GTX1660ti). These GPUs are not currently supported by the ACEMD2 app.
Admins are working on ACEMD3 app which will support Turing based GPUs. Hopefully this will be released soon.
There is currently no short tasks in the queue.

Until the new app (ACEMD3) is released, you should assign this host to a venue which receives work only from the ACEMD3 queue, as the other two queues have the old client, which is incompatible with the Turing cards.

I would like to contribute some useful results here with my Alienware laptop but I have a high failure rate which I would like to resolve here. The GPU in my laptop is a Geoforce 660M. The OS I am using is uptodate Windows 10.

I would appreciate it if a tech person could narrow down the reason or reasons why I am experiencing such a high failure rate.

I would like to contribute some useful results here with my Alienware laptop but I have a high failure rate which I would like to resolve here. The GPU in my laptop is a Geoforce 660M. The OS I am using is uptodate Windows 10.

I would appreciate it if a tech person could narrow down the reason or reasons why I am experiencing such a high failure rate.

I thought at one point when I saw the acemd2 long task buffer dwindle down that was in preparation of the project deprecating the acemd2 applications and move on to the new acemd3 applications.

But then they added a lot more acemd2 tasks to the buffer and now the acemd3 tasks have dwindled down to nothing.

Just the opposite of what I expected. Who knows what is up with the project? Seems like a lot of wasted effort developing and testing the new acemd3 app that finally removes the yearly aggravations of expired licenses and no sign of significant project acemd3 task work has appeared showing the project is back in gear.

I looking in to tasks, some tasks failed on another users too.
http://www.gpugrid.net/workunit.php?wuid=16845665
http://www.gpugrid.net/workunit.php?wuid=16845047
http://www.gpugrid.net/workunit.php?wuid=16842720
http://www.gpugrid.net/workunit.php?wuid=16837588
http://www.gpugrid.net/workunit.php?wuid=16835265
http://www.gpugrid.net/workunit.php?wuid=16833172

I looking in to tasks, some tasks failed on another users too.
http://www.gpugrid.net/workunit.php?wuid=16845665
http://www.gpugrid.net/workunit.php?wuid=16845047
http://www.gpugrid.net/workunit.php?wuid=16842720
http://www.gpugrid.net/workunit.php?wuid=16837588
http://www.gpugrid.net/workunit.php?wuid=16835265
http://www.gpugrid.net/workunit.php?wuid=16833172