Isn't this part of AMD's plan to support the HSA memory management that is being put into the latest 4.14 kernel?

Regarding MB's on GPU, it has been available from a time long before AP. So you should be able to find it.
And AP's errors out on RXxx0's under windows too (they run fine on the HD7770). There is a bug in the code somewhere (either the driver or the app). For a short time I had Raistmer looking into it, but he seems to be busy with other things.

Its not that Grant, its the simple fact that I am getting an error when AP tries to start crunching on my GPU. As per this thread:

https://setiathome.berkeley.edu/forum_thread.php?id=82285

What about MB?

Unfortunately I am still waiting for the ability to crunch seti WU on my GPU once again. Hopefully that time will come soon. :)

Your resource share determines what does & doesn't get processed.

I see that your system is pretty much identical to mine.

So if I can get 20c a day, I would be rather satisfied. I was hoping to do 10.

I have an extra HD7770 crunching also, so perhaps I can get to 21 :)

Which is why I added my 2c worth, running on the assumption that if the underlying dispatch system works better then improved deadlines would be a likely outcome ;)

The deadlines are set by the project, and Jeff's initial numbers show that even as things are, there's no need for such long deadlines.

This is off topic from deadlines, but is also a major cause of bloating.

ausymark wrote:

I'm going to suggest what I think might be a simple system that may help matters.
...
...
So does any of the above have merit and is it simple enough to be easily implemented?

Cheers

Mark

Yes, it definitely has merit, but I don't think any changes relating to quota management are likely to be easily implemented.

The existing system attempts to do some of what you suggest. If you look at the "Applications details" for a given host (for instance, yours would be here), you'll already find fields for "Average turnaround time" and "Max tasks per day", for each application that can be sent to that host.

In general, I suspect your proposal would probably be more restrictive on new hosts, but perhaps overly generous for existing ones. For new hosts, the initial value for "Max tasks per day" is 33. I think that number is much too high as it is, notwithstanding the fact that the value in that field is somewhat misleading. As I recall, the project applies a multiplier to that value to calculate the true maximum, and my recollection is that the multiplier is 8. (If anyone can point to someplace that would verify or refute that number, please do.)

That initial setting is then incremented by 1 for every task that is completed and validated, so it can get to be quite a huge number for reliable hosts. Theoretically, the number is decreased for each time a task is marked as an Error or Invalid (the latter being somewhat questionable). It can never drop lower than 1, but with the multiplier, and with the scheduler having multiple applications to choose from for hosts running stock), that number is kind of meaningless.

Even for hosts with huge "Max tasks" numbers, there are already two limiting factors in play. One is the maximum of 100 CPU tasks per host and 100 tasks per GPU. The other is the "Store at least nn days of work" and "Store up to an additional nn days of work" combination, controllable through user/host Preference settings. Each of these has a maximum value of 10 days which, even in extreme cases, should limit a host to no more work than it can process in 20 days. If that value is less than the maximum allowed by the other limits, that's where it should be capped. Otherwise, the other limits should come into play and, in the case of the most productive hosts, should be far less than 20 days. So, given all that, why a host with a greater than 20-day average turnaround is able to download more than 1 or 2 tasks at a time is beyond me. :^)

3) No matter how fast a host is its real performance is how many WU it uploads per day

Make that Validates.
Some host upload a lot of results, but they don't validate.

>>> Agreed ;)

Firstly there should be a 30 day average of WU processed per day. This allows for changes in operation and/or new hardware being introduced onto the host. To be calculated once per day. Note: Only the average needs to be stored, not an array of daily WU.s

The Average turnaround time for each application actually gives a good indication of how long it takes to return work.