[QUOTE=axn;536382]You've made an excellent argument to stop LL and only hand out PRP. :smile:[/QUOTE]Where the software/hardware combination can run either, yes. I've switched nearly all my primality testing from LL to PRP on cpu and gpu.

Some older gpus with very good DP/SP ratio, but OpenCL below 2.0, can't run gpuowl, so can't run PRP. I have a Tesla C2075 trudging through LL DC, at about 2/week in 53M, in CUDALucas, for example. (Which lacks even the Jacobi check, but the gpu has ECC ram, and I haven't yet had a bad final residue on it.)

PRP also needs DC. Since PRP is new, it has had very little. While it's more reliable than LL, due to the excellent GEC, there have been found errors outside the GEC protected code. Lots of PRP DC are needed to provide a big enough statistical sample to gauge what the PRP/GEC reliability figure is in practice.

It would be good for the GIMPS project if some top producers did more DC, either LL DC or PRP DC or both. And transitioned more completely from LL to PRP on their first tests.

And as Woltman occasionally reminds us, there might be a missed prime lurking in the ~2% of LL tests that have bad residues, that have waited years for a double check.

I don't know that there's any good solution to a user running unreliable hardware, either through lack of knowledge of the problem or lack of interest in improving reliability.

I'm not sure if this is a bug or not, but on the GPU72 site, if you log in on one version (say, the version whose language is determined based on your browser) and then switch to another language, the site will ask you to log in again to access your account. As I presume all the languages are on the same server, shouldn't one login suffice for all languages?

[QUOTE=Dylan14;536402]As I presume all the languages are on the same server, shouldn't one login suffice for all languages?[/QUOTE]

This is how HTTP Basic Auth works. Even though all the different language subdomains are indeed on the same server, as far as your browser is concerned they are different.

I came home from work about quarter to eleven CST to find no mfaktc running on my sole surviving GPU, a GTX 1060. .bat file restart attempts failed instantly. From command line, trying to run 'mfaktc -st' ended in an error message about mismatches in CUDA versions in different contexts. After mucking about a bit, I had the bright idea to just update the graphics driver. The nvidia installer could not find any devices requiring the driver because I only use the card for computing, and run the display from the onboard Intel.

I am shut down for TF, at least for the moment. At which moment I am too tired, and working on being too "relaxed" to pursue reconnecting the 1060 by whatever compatible cable, preferably DVI I can dig up to update the driver.. Meanwhile, I am down to a very laid-back 'garden' of an i7 6700k (4 cores, 1 worker, 4.3 GHz), and an i7 9700k (6 of 8 cores, 1 worker, 4.3 GHz). Both doing LLDC with DDR4-3200, dual rank or equivalent DRAM.

Life has setbacks. Deal with it However, my guess is that Win 10 updated something that broke my mfaktc.

[QUOTE=kladner;536541]I came home from work about quarter to eleven CST to find no mfaktc running on my sole surviving GPU, a GTX 1060. .bat file restart attempts failed instantly. From command line, trying to run 'mfaktc -st' ended in an error message about mismatches in CUDA versions in different contexts. After mucking about a bit, I had the bright idea to just update the graphics driver
....

Life has setbacks. Deal with it However, my guess is that Win 10 updated something that broke my mfaktc.[/QUOTE]
Maybe [URL]https://www.lifewire.com/how-to-roll-back-a-driver-in-windows-2619217[/URL] helps.
Finding out why it went awry and preventing a recurrence is needed too. It should not have updated to an incompatible version though.

[QUOTE=kriesel;536552]Maybe [URL]https://www.lifewire.com/how-to-roll-back-a-driver-in-windows-2619217[/URL] helps.
Finding out why it went awry and preventing a recurrence is needed too. It should not have updated to an incompatible version though.[/QUOTE]
Thanks for the link. After going through some of the suggested procedures I have mfaktc running again. I think it was the "Update driver" approach that fixed it after a few attempts with the different options available.

It seems some assignments are either being poached or being reassigned to other users. I should have 400 outstanding assignments, but GPU to 72 says I only have 283.

[QUOTE=ixfd64;536625]It seems some assignments are either being poached or being reassigned to other users. I should have 400 outstanding assignments, but GPU to 72 says I only have 283.[/QUOTE]

Can you give me any examples?

There's no recycling going on, and everything being given out is actually "owned" by GPU72.

[QUOTE=chalsall;536639]Can you give me any examples?[/QUOTE]

Hmmm... It looks like our "friend" Niels_Mache_Nextcloud is working "off the books" again... Not directly related to you, but [URL="https://www.mersenne.org/report_exponent/?exp_lo=107879231&full=1"]107879231[/URL] is an example of him blindly redoing work which someone else had already done.

Damn, I wish he wouldn't do this. There's no way I can predict what he'll poach, and it discourages legitimate participants.

I'll have another word with him. And it definitely doesn't help that George is often unresponsive to requests to manually add results that have been rejected by the server.

[QUOTE=ixfd64;536656]I'll have another word with him.[/QUOTE]

Thanks.

[QUOTE=ixfd64;536656]And it definitely doesn't help that George is often unresponsive to requests to manually add results that have been rejected by the server.[/QUOTE]

It's a small consolation, I know, but you /do/ get the credit on GPU72 for any poached TF assignments.