The other four are crunching PrimeGrid for the moment.

Barry

I know we're all having problems getting WUs for NVidia cards, but just to confirm:
I have a machine that's running with a 1060 and 1070 Hybrid that won't get WUs. This machine also has a Radeon Pro WX5100, and I still get Collaz Wus for that card.
Isn't this fun? :)

---

Have only AMD R7 Crossfire with Boinc 7.10.2 (Beta-Test from boinc.Berkeley.edu).
Since disconnection the old Collatz and connect the new one (three weeks ago). No problems since this time.

Fixed it then?

Apps appeared at 16:57 BST and new GPU WUs have appeared -- WU Hoo!

Same here, I just started to receive WUs again. The Issue seems to be fixed...

Regards,
Senilix

Fine at this end as well with new work.

Slicker, we are all curious as to what happened.

Both my machines received work also.

thanks

Same here -- all workstations are now receiving work.

Well, rats! Got to the party a bit late; one workstation isn't getting work - because they're aren't any available?

---

Now all is good! Thanks.

Barry

Well, rats! Got to the party a bit late; one workstation isn't getting work - because they're aren't any available?

All mine now have have work, I was out of town yesterday due to my son have a baby, gotta see the grandkids ya know!!
Now that I'm all my Windows machines are now getting Nvidia tasks as well as AMD tasks. My Linux machines always did get Nvidia tasks from when they first started flowing.

I don't think it's a lack of WUs. According to the messages when asking for work, I'm requesting a bunch of time, but the server isn't returning any work. Thinking maybe the host is marked not reliable or something.

---

I'm testing the validator, work generator, assimilator, and applications. It may or may not work which means you may or may not get credit for your work. There is still a lot of work to do but I'm making progress.

Hi Jon,

Started to notice CPU work units are finally beginning to validate, some inconclusive and some validating fine.

However, the ones which have validated fine give no credit at present.

Is this still on the to do list?




Thanks as always for all the work you're putting in!

Jack

Getting this also.

Thanks
Conan

Well it looks like I didn't get any credit for over 540,000 seconds of CPU work on my Windows machine. No credit awarded and now the WU has been deleted.

That sucks a fair bit.

The WU was validated but no awarded credit.

I have 3 more on my Linux machines, so I will see what happens there.

I know that a lot of work is still being done by Slicker and it is not his full time job, I will wait and see what happens.

Thanks Slicker for the hard work of getting the project back up.

Conan

Just wondering what happened to the Windows CPU WUs and if the credit can be recovered? Mainly because I spent 154 Hours on that particular WU and then to have it deleted without credit after being validated, was disappointing.

How are the efforts with the CPU work units coming along?

I have 2 Linux work units that have finished but saying validation is inconclusive, this is on 2 different machines. Both ran well over 100 hours.

Conan

None of the WUs should ever end up as inconclusive because they are either valid or not. The validation is done within the WU. e.g. the CPU WUs doulble check every new "high" using a separate algorithm and if they don't agree, it fails. If they do, it should validate. There shouldn't an "inconclusive". I'm going to turn off the file deleter so that once I figure out what is going on I can re-validate the tasks so you should get credit.

Now all is good! Thanks.

Barry

I re-ran the update versions which inserts the server records required for the scheduler to send the work. I'm not 100% sure why it got screwed up but I think it had to do with opencl_nvidia vs opencl_nvidia_gpu plan class stuff that happened last Thursday. Once again, more people weighing in on what might be wrong help me get it back on track faster. Thanks guys! I also found a bug in the BOINC error reporting from this so I'll be sure to forward that to the BOINC developers as well.

None of the WUs should ever end up as inconclusive because they are either valid or not. The validation is done within the WU. e.g. the CPU WUs doulble check every new "high" using a separate algorithm and if they don't agree, it fails. If they do, it should validate. There shouldn't an "inconclusive". I'm going to turn off the file deleter so that once I figure out what is going on I can re-validate the tasks so you should get credit.

Update to my original post - CPU work units are now picking up credit, seemingly since the new app was released (however these are still "old app" work units at present, since I suspended a few to see how the situation developed)

Has it ever been a case where the validator has required a certain number of samples to get a pattern before granting credit to everyone?

Alternatively, do you think it may just be something in the coding you've done for the new app that's allowed the credit system to see all CPU tasks again?

Those that came up valid after some time sat at inconclusive, were previously granted 0 credit, but since the deleter has gotten rid of those WUs, I don't know if I ever eventually received the credit for those. Certainly the others I suspended now are, and were downloaded at the same time...?

Either way, happy to see you get back on track with the project and happy to let the credit situation slide given the work you're doing to fix it. Couple of zero credit tasks is far outweighed by having your project hijacked by the cheats!

Thanks again,

Jack

Has it ever been a case where the validator has required a certain number of samples to get a pattern before granting credit to everyone?

Yes, that's the way the project started. But given that some hosts trash over 1000 WUs a day and their owners aren't smart enough to check them, there was a problem with people getting credit because there were so many failures that it would take months to get credit for a WU and that also meant months for the WU to remain in the database which increased the size which caused performance issues. MySQL works best when the entire database fits in RAM and since very little data is re-used in BOINC, the cache hits aren't the greatest so there's a lot of disk i/o if it doesn't fit in RAM. That, and the only way for it to work is for me to hard code all the parameters that you have in the config file since changing the sieve size. That would mean de-optimizing it so that it can run on the oldest and slowest GPU. That would be horrible for the new GPUs. They'd go from 99% utilization to 20% utilization with credit reduction to match.

Has it ever been a case where the validator has required a certain number of samples to get a pattern before granting credit to everyone?

Yes, that's the way the project started. But given that some hosts trash over 1000 WUs a day and their owners aren't smart enough to check them, there was a problem with people getting credit because there were so many failures that it would take months to get credit for a WU and that also meant months for the WU to remain in the database which increased the size which caused performance issues. MySQL works best when the entire database fits in RAM and since very little data is re-used in BOINC, the cache hits aren't the greatest so there's a lot of disk i/o if it doesn't fit in RAM. That, and the only way for it to work is for me to hard code all the parameters that you have in the config file since changing the sieve size. That would mean de-optimizing it so that it can run on the oldest and slowest GPU. That would be horrible for the new GPUs. They'd go from 99% utilization to 20% utilization with credit reduction to match.

And we definitely didn't go back to that for a brief time since restarting the project?

Was just wondering if that had been the case with some of the 0 credit tasks we were experiencing last week?

Also, in that scenario, would a limit on tasks per day that raises with successful tasks and falls with failed jobs be any use? I know a few other Boinc projects have done that or are looking at it?

Tried attaching to the project again after a spell away - can't get any work.
The host has ran Collatz in the past and is quite happily running Moo now so I know the GPU works.

Host is - https://boinc.thesonntags.com/collatz/show_host_detail.php?hostid=811276

Detached the project.
Installed VC++ 2017
Re-attached using the "http://" link, (got a message in the logs - "This project is using an old URL. When convenient, remove the project, then add https://boinc.thesonntags.com/collatz/"!)
Requesting work but not getting any.

Using a GTX1070 with slightly old but working drivers, reporting as both CUDA and OpenCL capable.
16/05/2018 21:14:57 | | CUDA: NVIDIA GPU 0: GeForce GTX 1070 (driver version 378.49, CUDA version 8.0, compute capability 6.1, 4096MB, 3046MB available, 6707 GFLOPS peak)
16/05/2018 21:14:57 | | OpenCL: NVIDIA GPU 0: GeForce GTX 1070 (driver version 378.49, device version OpenCL 1.2 CUDA, 8192MB, 3046MB available, 6707 GFLOPS peak)

sched_ops and work_fetch flags enabled:
16/05/2018 21:37:01 | collatz | update requested by user
16/05/2018 21:37:01 | | [work_fetch] Request work fetch: project updated by user
16/05/2018 21:37:03 | collatz | sched RPC pending: Requested by user
16/05/2018 21:37:03 | | [work_fetch] ------- start work fetch state -------
16/05/2018 21:37:03 | | [work_fetch] target work buffer: 172800.00 + 8640.00 sec
16/05/2018 21:37:03 | | [work_fetch] --- project states ---
16/05/2018 21:37:03 | collatz | [work_fetch] REC 0.000 prio -0.000 can request work
16/05/2018 21:37:03 | | [work_fetch] --- state for CPU ---
16/05/2018 21:37:03 | | [work_fetch] shortfall 1218588.22 nidle 0.00 saturated 97880.19 busy 0.00
16/05/2018 21:37:03 | collatz | [work_fetch] share 0.000 blocked by project preferences
16/05/2018 21:37:03 | | [work_fetch] --- state for NVIDIA GPU ---
16/05/2018 21:37:03 | | [work_fetch] shortfall 89839.77 nidle 0.00 saturated 91600.23 busy 0.00
16/05/2018 21:37:03 | collatz | [work_fetch] share 1.000
16/05/2018 21:37:03 | | [work_fetch] ------- end work fetch state -------
16/05/2018 21:37:03 | collatz | [work_fetch] set_request() for NVIDIA GPU: ninst 1 nused_total 0.00 nidle_now 0.00 fetch share 1.00 req_inst 1.00 req_secs 89839.77
16/05/2018 21:37:03 | collatz | [sched_op] Starting scheduler request
16/05/2018 21:37:03 | collatz | [work_fetch] request: CPU (0.00 sec, 0.00 inst) NVIDIA GPU (89839.77 sec, 1.00 inst)
16/05/2018 21:37:03 | collatz | Sending scheduler request: Requested by user.
16/05/2018 21:37:03 | collatz | Requesting new tasks for NVIDIA GPU
16/05/2018 21:37:03 | collatz | [sched_op] CPU work request: 0.00 seconds; 0.00 devices
16/05/2018 21:37:03 | collatz | [sched_op] NVIDIA GPU work request: 89839.77 seconds; 1.00 devices
16/05/2018 21:37:04 | collatz | Scheduler request completed: got 0 new tasks
16/05/2018 21:37:04 | collatz | [sched_op] Server version 711
16/05/2018 21:37:04 | collatz | This project is using an old URL. When convenient, remove the project, then add https://boinc.thesonntags.com/collatz/
16/05/2018 21:37:04 | collatz | Project requested delay of 121 seconds
16/05/2018 21:37:04 | collatz | [sched_op] Deferring communication for 00:02:01
16/05/2018 21:37:04 | collatz | [sched_op] Reason: requested by project
16/05/2018 21:37:04 | | [work_fetch] Request work fetch: RPC complete
16/05/2018 21:37:09 | | [work_fetch] ------- start work fetch state -------
16/05/2018 21:37:09 | | [work_fetch] target work buffer: 172800.00 + 8640.00 sec
16/05/2018 21:37:09 | | [work_fetch] --- project states ---
16/05/2018 21:37:09 | collatz | [work_fetch] REC 0.000 prio -0.000 can't request work: scheduler RPC backoff (115.99 sec)
16/05/2018 21:37:09 | | [work_fetch] --- state for CPU ---
16/05/2018 21:37:09 | | [work_fetch] shortfall 1218589.39 nidle 0.00 saturated 97880.19 busy 0.00
16/05/2018 21:37:09 | collatz | [work_fetch] share 0.000 blocked by project preferences
16/05/2018 21:37:09 | | [work_fetch] --- state for NVIDIA GPU ---
16/05/2018 21:37:09 | | [work_fetch] shortfall 89895.59 nidle 0.00 saturated 91544.41 busy 0.00
16/05/2018 21:37:09 | collatz | [work_fetch] share 0.000
16/05/2018 21:37:09 | | [work_fetch] ------- end work fetch state -------
16/05/2018 21:37:09 | | [work_fetch] No project chosen for work fetch

Interestingly, the work_fetch says "16/05/2018 21:37:09 | collatz | [work_fetch] REC 0.000 prio -0.000 can't request work: scheduler RPC backoff (115.99 sec)" but doesn't give a reason why.
The backoff counts down to zero with each fetch then resets to 600 and starts counting down again.
I don't have the "Use CPU" box ticked in preferences so I can understand why I'm not getting any CPU tasks but no idea why there's no Nvidia tasks downloading.
Also I don't understand why the work_fetch share is 0.00 for the GPU as it's set to 1000 in my preferences here?

None of the WUs should ever end up as inconclusive because they are either valid or not. The validation is done within the WU. e.g. the CPU WUs doulble check every new "high" using a separate algorithm and if they don't agree, it fails. If they do, it should validate. There shouldn't an "inconclusive". I'm going to turn off the file deleter so that once I figure out what is going on I can re-validate the tasks so you should get credit.

Thanks for this Slicker,

Just had another WU that had validated (like my 1st one), disappear from my account list (just like my 1st one). This time it was on a Linux machine and ran for about 420,000 seconds.
Both were awarded Zero credit.
Have one still there (an inconclusive) and another still running.

I am glad that you are letting me post as I still have Zero RAC, so thanks for that.

Thanks for all your hard work.

Conan