The last work my computer processed was over half a year ago.

May be it has an easy solution: Try updating your BOINC version from 7.16.11 to the newer 7.16.20 and resetting Gpugrid project.
After that, additionally, some patience is needed, as soon as work is lately scarce at Gpugrid...
Your GTX 1660 system should work.
Your GT 730 wouldn't

The last work my computer processed was over half a year ago.

PS: Don't worry if initial estimation for an ACEMD 3 task completion is of a magnitude of hundreds of days.
A regular GTX 1660 should complete it in less than 48 hours, thus getting mid bonus (+25%) with no problem.
Congrats, and welcome in your come back!

Thanks!

ACEMD 3 task

from what it looks, ACEMD 3 now is running out of new tasks :-(

I also didn't see new tasks appear with my Linux boinc version 7.16.16.
I think here is no updates available.

There is the latest 7.18.1 from the Ubuntu 22.04 LTS distro. I know of that one. Whether the other Linux distros have that version available I don't know.

I have no issues getting GPUGrid work every day on multiple hosts on Ubuntu 20.04 using a 7.17.0 client I use as a team client we compiled ourself.

Also have used a 7.18.1 client I compiled on my development partition and it works and gets tasks also.

I get new tasks almost every day. they are _0 which means they are brand new freshly minted tasks.

so new work is still coming out, but not in large volumes. so if you want work you need to ask for it very often to catch when they are available. my systems are set to request work every 60 seconds.

---

I get new tasks almost every day. they are _0 which means they are brand new freshly minted tasks.

so new work is still coming out, but not in large volumes. so if you want work you need to ask for it very often to catch when they are available. my systems are set to request work every 60 seconds.

my systems, too, are set to request work in short intervals.
However, I have not gotten any new ACEMD3 tasks for the past 3 days.
From what I saw, your systems run on Linux, mine on Windows.
Which means GPUGRID now provides ACEMD3 tasks for Linux only :-(

I get new tasks almost every day. they are _0 which means they are brand new freshly minted tasks.

so new work is still coming out, but not in large volumes. so if you want work you need to ask for it very often to catch when they are available. my systems are set to request work every 60 seconds.

my systems, too, are set to request work in short intervals.
However, I have not gotten any new ACEMD3 tasks for the past 3 days.
From what I saw, your systems run on Linux, mine on Windows.
Which means GPUGRID now provides ACEMD3 tasks for Linux only :-(

there is undoubtedly an element of luck involved, not simply Linux vs. Windows.

This Windows system also hasn't had issue getting tasks: https://gpugrid.net/show_host_detail.php?hostid=534811

ACEMD3 work is scarce for everyone.

---

GPU Grid need to be removed from all compétitions.
No any respect to cruncher. No any reaction from admin.
Nice research, but no any WU. No reactions. Nothing !! Is this PRJ still active ???

---

GPU Grid need to be removed from all compétitions.
No any respect to cruncher. No any reaction from admin.
Nice research, but no any WU. No reactions. Nothing !! Is this PRJ still active ???

1. GPUGRID is not involved in any competitions. so what should they be removed from exactly?

2. the project admins have been very engaging over the last few months. all you need to do is read the threads, especially those in the News forum regarding the Python tasks and new ACEMD4 applications/tasks.

3. GPUGRID work has always had periods where tasks were scarce, this is not new. the project has also adopted a new strategy of distributing fewer very long tasks instead of many short tasks. where were you when there were literally THOUSANDS of tasks available a few weeks ago? if you only run Windows, that's half of your problem. most of the tasks available recently have been for Linux. the other half is probably because you're not asking for work often enough.

obviously the project is still active if there are over 350 tasks in progress right now.

---

Yes GPU Grid is in compétition !
Look on SETIBZH and Formula Boinc !

Yes I only run Windows, all my host are "open" with death line of 3 days. So enough to get work,

You misunderstood. GPUGRID has nothing to do with these “competitions”. They are third party events that have nothing to do with GPUGRID’s organization or control. You need to take it up with the event organizer.

To get any work here lately, you need to have your system setup with a script to run every minute or so asking for more work. When work becomes available it’s snatched up quickly.

---

Well, the tasks availability has been really bad for the past few months.
Even worse: one of my hosts which is still trying to get GPUGRID work was lucky and received 2 WUs yesterday: however, both of them were terminated by the server :-(

I have been member here for more than 7 years, but I am sorry to say that the situation has never been as bad as it is presently :-(

And when someone here recently has criticized the lack of reponsiveness of the project people - unfortunately he is right, this is something I have found annoying over all the years.

To get any work here lately, you need to have your system setup with a script to run every minute or so asking for more work. When work becomes available it’s snatched up quickly.

I've been thinking about this suggestion, and I'd like to advise caution when using it.

A couple of years ago, I noticed that it takes much longer for BOINC to establish a connection with a project server when the secure https protocol is in use. And there has been much pressure from the user community in recent years for BOINC to use https for all purposes. Just at the moment, one of the regular competitions is placing an additional load on selected project servers.

The problem is particularly severe for smaller projects, like GPUGrid, which use a single web server for all project communications, including message boards. I commented at the time (message 55446) that I had been unable to reach this website over https for four hours, because an application failure was causing an excessive demand for tasks. I eventually got a PM through to Toni over http, and he (message 55449) took the project offline within 30 minutes - it was a real problem that needed fixing.

May I make a small suggestion? All the production tasks for this project last for a significant runtime - so there is no point in triggering further updates once work, sufficient for the host's resources, has been allocated. And BOINC has no native way of distinguishing between necessary work requests and general updates. Both require that https connection.

Anyone willing and able to pick up the challenge of developing a 'work request' script which suspends the flow of update requests when the host has active tasks for the project?

the project could also help alleviate this by simply setting their requested delay to something much greater than 31 seconds. since they have an IP block on their network for DDoS protection, and it seems to also expire around the 30-60s mark, having their own configuration telling clients to bang away every 30s leads to situations where people with multiple hosts at the same IP get themselves perpetually blocked from accessing the site, with through the web browser or via BOINC. I've brought this up before.


maybe like 2-5 minutes would be more appropriate. the shortest tasks ive seen from this project have been about 20 mins crunch time, and that was like 2 years ago. all the tasks now run for hours, literally no reason for a ~30 second project delay.

but the script solution to stop requesting work while you have active tasks can be done utilizing boinccmd, some regex, and some simple loops.

---

on the other hand: all these discussions would not be necessary if there was a sufficient number of WUs available :-)

the issue of a cooldown/delay being too short would still be a problem.

but the project can't just invent work for the sake of doing work. it needs to be meaningful and align with their goals.

---

the issue of a cooldown/delay being too short would still be a problem.

but the project can't just invent work for the sake of doing work. it needs to be meaningful and align with their goals.

WUs can be fabricated, but I would not crunch them. What would be the point?

There are still other worthy projects to crunch. Though Einstein seems to have a work shortage itself, when I tried to crunch it, a day or two ago. There is folding@home. Though their inter phase, can be somewhat temperamental.

As far as this project, the last few years have been rough, and I have been here since 2009. There are, not only, work shortage, but the new app development is also worse than before. The python still needs more work. When it crashes, it causes boinc manager to crash as well. I never remember seeing this with previous betas. It still more work, with low GPU usage, long periods of non work, along with many crashes. This is mainly due to lack of resources.

What else can you say?