My i7-8700 is left with nothing to do.
http://www.gpugrid.net/results.php?hostid=475515

I will put it on Folding.

My Ryzen 1700 is still busy with plenty of QC tasks… and there are many more in the queue. How can it be that your 8700 doesn't get any? This system is also a Linux based one, is it not?

---

I would love to see HCF1 protein folding and interaction simulations to help my little boy... someday.

Yes, that is the point, there are plenty of tasks available. It seems that they just place a limit on them. I think it is to guard against machines that produce a lot of errors, but mine doesn't. I think the limit should be increased.

Note that my i7-8700 was running QC only, and ran through a lot of them per day. I have a Ryzen 1700 also, but run just four cores on QC (two work units running two cores each). That machine has no problem getting work, and I will let it run. But if they ever want to get their mountain of work done, they will have to let the high-productivity machines get them. The Androids won't do it.

If somebody has an idea of where the daily quota setting limit is, I'd like to hear.

As you probably know, there was some discussion of it earlier, though it does not tell you much.
http://www.gpugrid.net/forum_thread.php?id=4823

And Richard Hasselgrove (as usual) has the best handle on it:
http://www.gpugrid.net/forum_thread.php?id=4825

Jim,

Your last work unit reported at 07:13 with an error. I don't see any others after that. Is it possible that server put your machine in "time out" until you reported a new work unit that validates?

I've not seen a limit yet on the work units for CPU. I'm running a i7 6950X and it been steadily busy since I got it running under Ubuntu. I usually get about 24 at a time which corresponds to my daily limit of 0.5 days + 0.1 extra

Z

---

Your last work unit reported at 07:13 with an error. I don't see any others after that. Is it possible that server put your machine in "time out" until you reported a new work unit that validates?

That could be it, but I don't know.

If so, they need to increase the limit, or machines will be idle too often. I don't know of any other project that shuts down the supply of work after only one error (which could happen for a variety of causes).

EDIT: I keep a 0.1 + 0.5 day buffer on all my machines, which is the default. It seems to be the reverse of yours, but it should not matter much.

Second EDIT: There are a couple of errors. They say:

CondaHTTPError: HTTP 000 CONNECTION FAILED for url <https://repo.anaconda.com/pkgs/pro/linux-64/repodata.json.bz2>
Elapsed: -

An HTTP error occurred when trying to retrieve this URL.
HTTP errors are often intermittent, and a simple retry will get you on your way.

I think this must be due to the intermittent connections and timeouts I get with GPUGrid. There may be no cure for that, but at least they could increase whatever error limits they have.

I increase the daily quota because new QC jobs are short. Failures and successes will cause the quota to go up and down for your host, as per BOINC heuristics.

The CondaHTTPError is a connection error between your host and Conda cloud, not GPUGRID.

OK, I will try it again later and see how it goes.

Found my r7 1700 system idling with a daily quota of 4 hit. Why would so many WUs fail?

Found my r7 1700 system idling with a daily quota of 4 hit. Why would so many WUs fail?

CondaHTTPError: HTTP 503 SERVICE UNAVAILABLE: BACK-END SERVER IS AT CAPACITY for url

Been seeing that the last few errors I've had. Not sure what it means.

---

Found my r7 1700 system idling with a daily quota of 4 hit. Why would so many WUs fail?

Good question.
But it makes it difficult to devote an entire PC to it. You need to be running something else in case your quota is hit. I hope they can fix it.

@Zalster: That conda was getting too many download requests from users so it refused to download the packages on your machine at that moment. Should work next time I assume.

My system gets random CondaHTTPErrors as well. From a layman's perspective this seems to be a bottleneck.

Are volunteers possibly risking being blacklisted by thrashing the Conda Cloud? Is there another way for the project to distribute/cache the necessary packages?

@Zalster: That conda was getting too many download requests from users so it refused to download the packages on your machine at that moment. Should work next time I assume.

Yes it did, but in the meantime 40 QC units "erred out" . Only thing that saved me from a "time out" is that I had more QC units in the cache that validated later and help me avoid being locked out.

I agree, it does seem like a bottleneck. If and when the Windows QC goes mainstream, I would expect to see a huge up spike in these "errors" and lockouts.

---

Indeed the new short WUs probably contact the conda cloud too often. Even if there is no download, just checking for new versions (which I don't think we can really avoid) triggers the block. We may need to recreate the WUs as larger blocks.

Indeed the new short WUs probably contact the conda cloud too often.

I was about to say the same thing, though on a different basis. My Ryzen 1700, running two work units (2 cores each) has no problem with the Conda server, but each work unit usually runs over 30 minutes. My i7-8700 was churning through them at 10 minutes (or less), and got the errors. I think we need to somehow back off, and larger work units make sense to me.

I'll look into making the WUs larger next week. For the weekend I don't want to break stuff so it will keep on running as is, sorry.

Can you give me an estimated runtime of these WUs to know how many of them to pack together?

Can you give me an estimated runtime of these WUs to know how many of them to pack together?

Hello Stefan, Linked below is my r7 1700 system running at 3.9ghz with 2933mhz ram. You can see all of the run times.

http://www.gpugrid.net/results.php?hostid=424454