if you're 1 second past the timeout, or 2hrs past the timeout, it makes no difference in regards to making a successful connection. I've tested this thoroughly. this is assuming you only have a single system requesting a connection via that IP address.

also returning a completed task with your schedule request seems to increase the likelihood that you will receive tasks in return. which is why my other systems with faster GPUs and many GPUs crunching tasks more often didnt seem to have any issue staying topped up. the only system I had an issue with, which is restricted to a single task (takes 27hrs to process), I had forgot to check on it and it completed its lone task, returned it, got unlucky without a task sent to me (the command wasnt running at this time), and then it gave up trying for several hours until I noticed it, re-initiated the looping command, and finally got the task.

there also seems like there was a possibility of a server-side scheduler issue at the time. but either way, my command in no way prevented me from getting the task I was asking for. it just allowed me to keep asking more often without having to manually sit there and click the Update button. as long as you don't try to ask for more work faster than ~30sec (per IP, you must account for other systems making requests) you'll never have an issue with this.

---

Someone suggested a while ago that having more than a certain number of machines attached reduced your chances of getting work on the additional ones. In other words, it wasn't just the total requests, but where they came from. I didn't pay much attention to it. But when I have even two machines running GTX 1070's attached, I often have problems accessing the website. Maybe you can get it to work with the right timeouts.

it was me, I'm the one who mentioned that lol. but the system in question is the only one running at this IP address so it's not a factor in this particular instance.

I also run a custom BOINC client to be able to better control the timeout from the project. I usually restrict it to delay schedule requests for 10 mins (default is like 30 seconds last I checked), which worked well when I had like 4-5 systems running at the same location.

I also wrote a script that tried to emulate this behavior of a forced longer timeout so you didn't need a custom client. if you search my past posts you can probably find it. it seemed to work "ok" in my tests, but YMMV.

---

Yesterday, I wrote:

am I still the only one whose machines don't receive new tasks since this morning?

during last night, I did receive new tasks :-)

I also wrote a script that tried to emulate this behavior of a forced longer timeout so you didn't need a custom client. if you search my past posts you can probably find it. it seemed to work "ok" in my tests, but YMMV.

I was wondering if it was you. You have investigated it well enough, but it seems that each person may need a custom script. That will be a problem.

Yesterday, I wrote:

am I still the only one whose machines don't receive new tasks since this morning?

during last night, I did receive new tasks :-)

again, no new tasks could/can be downloaded all day long :-(
what's the problem ?

Yesterday, I wrote:

am I still the only one whose machines don't receive new tasks since this morning?

during last night, I did receive new tasks :-)

again, no new tasks could/can be downloaded all day long :-(
what's the problem ?

all 4 of your systems show at least one task in progress. judging by how long these task run and the relative speed of the GPUs on your systems (the 750tis just barely make the 5-day deadline), you seem to have the appropriate amount of tasks already. Why do you think there's a problem?

---

Why do you think there's a problem?

simply because in all the years before (I've been crunching for 6 years), each GPU could download 2 tasks, regardless of the crunching time per task.
So something seems different now.

Further, as you correctly stated, the 750tis barely make the 5-days-deadline, and I guess that I am not the only one with such a card. So I don't understand why this deadline is not being extended once such huge long-runners are being distributed.

Back to the download problem: of course, it would not make sense anyway to download 2 new tasks at a time with the 750tis; but for the 970 and the 980ti, it would make sense (particularly in times where once and so often there are no new tasks available, like exactly right now).

BOINC keeps track of the total time it will take to compute the jobs in your cache, and compares that to your cache size that you have specified in the compute settings.

if you have 1 task that takes 5 days to complete, and your compute preferences are requesting 1-5 days of work, then with your 1 task, your cache is filled and it wont ask for more.

in this instance, increasing the cache size preference in order to cache 2 tasks will make no sense, as after 5 days, the task will expire and be sent to someone else.

the only thing that changed was the task size. and we've never had tasks that run this long before, so it might have not been long enough for BOINC's mechanisms to come into play.

as far as deadlines go. The goal of this, and any, project is scientific results. and since they are running the project, they are the ones that set the requirements for how long they want to wait for results. if they've determined that they want/need results in X number of days, that's their right, it's their project.

---

additionally, the outstanding resends seem to have dried up for the moment, so it'll probably be a little hard to get tasks for the next few days.

---

the only thing that changed was the task size. and we've never had tasks that run this long before, so it might have not been long enough for BOINC's mechanisms to come into play.

yes, maybe so

as far as deadlines go. The goal of this, and any, project is scientific results. and since they are running the project, they are the ones that set the requirements for how long they want to wait for results. if they've determined that they want/need results in X number of days, that's their right, it's their project.

I agree.

However, I don't think the 5 days deadline per task is absolutely mandatory for the result of the project.
The situation rather is that this time span was set long time ago, and ever since the tasks were lasting from a few hours to maximum 1 or 2 days, even with older cards (at least that's what I remember from the past 6 years I've been on board).

And now, with these unusual long-runners, probably no one at GPUGRID has taken into account that there are still many users with old cards which will barely or not at all be able to finish these tasks within 5 days.

In other words, I do not think (or hope) that their intention is to preclude that many users with older cards from crunching their tasks.

And now, with these unusual long-runners, probably no one at GPUGRID has taken into account that there are still many users with old cards which will barely or not at all be able to finish these tasks within 5 days.

But they certainly are aware of the issue. See Toni's post from 4 days ago where he explicitly mentions that the tasks are not meant for low powered cards.

https://www.gpugrid.net/forum_thread.php?id=5217&nowrap=true#56504

as you may have noticed, we sent a new batch of WUs for a new experiment. This time the WUs are rather large and require relatively new cards. For reference, should be ~18h on a 1080 Ti.

My emphasis.

And now, with these unusual long-runners, probably no one at GPUGRID has taken into account that there are still many users with old cards which will barely or not at all be able to finish these tasks within 5 days.

But they certainly are aware of the issue. See Toni's post from 4 days ago where he explicitly mentions that the tasks are not meant for low powered cards.

https://www.gpugrid.net/forum_thread.php?id=5217&nowrap=true#56504

as you may have noticed, we sent a new batch of WUs for a new experiment. This time the WUs are rather large and require relatively new cards. For reference, should be ~18h on a 1080 Ti.

My emphasis.

so hopefully this does not mean that if this new experiment works out well, in the future there will mainly come such tasks which require powerful cards.
On the other hand, if this is what will happen, there is not much the crunchers with less powerful cards can do about :-(

you could upgrade. even though the used market is a little shaken up right now, you can easily get a more capable GPU than a 750ti for not too much money. something like GTX 960/970/980 are still cheap.

it's not unreasonable for projects to evolve to take advantage of newer and faster hardware. it is unreasonable to expect a project to placate all users with very old hardware. all projects need to draw the line somewhere, and that line shouldn't be set in stone forever.

---

At least, provided that these kind of tasks were to become more common or even the standard workload in the foreseeable future, I don't see a reason why they couldn't adapt their 24 hrs return bonus slightly upwards to not penalize still relatively new (arguably less powerful and thus less important contributions) hardware that miss the deadline only by a small margin and are just shy of the 24hrs mark. And as seen before in numerous performance benchmarks here, there is still a large user base with 10series or 16 series cards that will inevitably miss this 24 hrs mark. Why not take that change in workload as an opportunity to change the credit calculation... That is to say, if you were to continue placing similar workloads in the foreseeable future. Increasing this mark by just 1-2 hrs, might give 2 yr old cards (16series) still a chance to make it in time for the bonus.

Definitely not able to upgrade in the near future at these steep prices that are blown out of proportion by the steep demand paired with the current supply situation. IMO the value proposition for new RTX 30series cards is there, but the price/value relation is way to skewed at the moment. It's a sellers and not a buyers market.

Let me know what you think.

you could upgrade. even though the used market is a little shaken up right now, you can easily get a more capable GPU than a 750ti for not too much money. something like GTX 960/970/980 are still cheap.

you are perfectly right!
My problem is not having no money to get a newer/better GPUs, but rather that the two boxes in which the two 750ti are crunching, are rather small ("mini-tower"). I was lucky to manage accomodating the 750tis a few years ago.
The boxes still work well (in on of them I upgraded the CPU from a 2-core to a 4-core, on the other one I upgraded the RAM), so I simply do not want to get rid of these PCs, if not absolutely necessary.
Once I have to replace them for any reason, I will of course get PCs with new and strong GPUs.
Until then, I was hoping to contribute to GPUGRID with my current 750tis.

today, on one of my 750ti, a task got finished after 430.782 seconds and was classified as "too late", no credits.

Whereas 2 days ago, on the other machine with a 750ti inside, a task got finished after 431,471 seconds and got 348,750 credit points.
So, obviously this all is lottery.

I still don't understand why the deadline is not increased at least by 1 day, so that also members with older cards can participate.
Since this obviously is not desired by the project, I stopped downlading GPUGRID and changed to Folding&Home. Which I am very sorry about after having participated in GPUGRID for 6 years.

http://www.gpugrid.net/workunit.php?wuid=27021719

it looks like in this case, even though you returned it within 5 days, you were processing a resend. the person before you missed their deadline, and it was resent to you, but shortly after that, the original person submitted their late result.

when processing resend, and there's a timeout involved, it becomes first come first serve, or first to the finish line, whatever analogy you prefer. even though the person submitted it late, they submitted it first, and you submitted your result about 4.5 days later. I know if you would have submitted your result earlier, you would have received equal credit, so there must be some grace period, maybe if two results come in within 1 day? I'm just guessing. but your result was over 4.5 days later, so i can understand that the validator might have some limits in this case.

but this WU already had a long delay. the first result was received 7 days after inception, and your result over 11 days. I know it's unfortunate, but that seems to be the "why"

---

Anyone else getting the impression that the latest batch of tasks, released in the last day or two, are running significantly slower than their predecessors?

everything seems normal here. everything I have in progress looks in line with historical data for those systems.

---