[QUOTE=storm5510;531922]I tried this earlier. I get icons with a red x and a lock symbol on them. It's trying to create a link instead of moving the file. It says in the properties, "Link (broken)(inode/symlink)."



I get the same message, but different library name. libcudart.so.10.0. I believe this refers to CUDA 10. A few months back, on the Windows drive, the 10 version stopped working. I had to revert it back to 80 to get it to run again.[/QUOTE]

Copy just the 6.5.14 file(if you can) and rename it to libcudart.so.6.5
Likely not ideal, but might be the easiest way assuming it eorks.

[QUOTE=kracker;531926]Copy just the 6.5.14 file(if you can) and rename it to libcudart.so.6.5
Likely not ideal, but might be the easiest way assuming it eorks.[/QUOTE]

I have the proper 6.5 file. Copying only creates a broken link, like before. I wonder if this has anything to do with permissions? It seems strange that it is locked in this one place.

[QUOTE=storm5510;531922]I get the same message, but different library name. libcudart.so.10.0. I believe this refers to CUDA 10. A few months back, on the Windows drive, the 10 version stopped working. I had to revert it back to 80 to get it to run again.[/QUOTE]

Ah... OK... Try running "apt-get -y install cuda-cudart-10-0" before running mfaktc.

Colab made a change to their VM a while back, which broke my payload. Naturally this happened just when the power fell out from under me, and I wasn't able to implement a fix (provided by (I believe) kracker) for several days.

I should recompile mfaktc to the new "native" environment. Still running only two screens; after "firing" my previous "kit" supplier, I just now have in hand a new motherboard which should support more than two monitors.

[QUOTE=storm5510;531930]I have the proper 6.5 file. Copying only creates a broken link, like before. I wonder if this has anything to do with permissions? It seems strange that it is locked in this one place.[/QUOTE]

I would try copying the file from bash and not the file manager gui and see what it says.

EDIT: Just try this and see if it works...

OK, this is becoming mind-bending for me. I tried the "apt-get" and got two lines of basically word-salad.

So, i deleted everything in the mfaktc folder. I took the [I]linux64.cuda65.tar[/I] archive there and extracted it. The folder structure is like this, relative to the parent folders:

[COLOR=DarkRed]/mfaktc
/mfaktc/mfaktc.exe
/mfaktc/lib/libcudart.so
/mfaktc/lib/libcudart.so.6.5
/mfaktc.lib/libcudart.so.6.5.14[/COLOR]

The first two in "lib" are "links to shared libraries," according to the properties. The bottom is actually a "shared library.

I still get the same library error message as above.

===================

[U]Edit[/U]: I was able to move the bottom item into the same folder as mfaktc.exe, and drop the ".14" from the name. No good.

This spectator feels your frustration. Though I have not run Linux in a long time, this sort of thing is OS agnostic. :bangheadonwall:

[QUOTE=kladner;531973]This spectator feels your frustration. Though I have not run Linux in a long time, this sort of thing is OS agnostic. :bangheadonwall:[/QUOTE]

I left the Windows hard drive in and untouched. All I would have to do is shut down, move the drive connectors and restart. If I do that, then it is giving up. I decided to try Ubuntu to learn a few things about it, and I have. Some here have never used anything but this. It's all about going with what you know.

Three screens!!!
 

The title says it all!!! :smile: :tu:

I don't know what other's experience with Asrock is like, but I will personally be avoiding them in the future. Sample size of one, but I don't have time for additional...

[QUOTE=chalsall;532025]I don't know what other's experience with Asrock is like, but I will personally be avoiding them in the future.[/QUOTE]When I first became familiar with them in 2005 they were relatively new as a brand, having been created as the "discount" brand from Asus in 2002. Their main focus (in my mind anyways) has always been more on low price and volume than high quality. In the last few years they've pushed more into higher-end gaming type stuff, but early opinions stick and I would much rather spend my money on Asus or Gigabyte, at least if I was building a system for me. If I was building a $200 check-email-surf-web system for my mother or similar I would consider ASRock.

Sadly, my own main system is now almost exactly 8 years old (2011-Dec-09) so it's high time that I replace it, unfortunately those funds won't be available for another year or so, so I keep plodding along. :s485122:

[QUOTE=chalsall;532025]The title says it all!!! :smile: :tu:

I don't know what other's experience with Asrock is like, but I will personally be avoiding them in the future. Sample size of one, but I don't have time for additional...[/QUOTE]

My main system has a Asrock board, had one before before I upgraded as well, I've built around 12-15 computers with them... no complaints for me personally... Sorry :razz:

On another note, can anyone guess my favorite motherboard manufacturer? Might be hard to guess.

My personal experience is that they are one of the lower quality motherboard manufacturers as well.

However, someone please correct me if I am wrong, when it comes to Radeon VII GPUs George's experience is that the ASRock branded ones are giving the fewest problems. Go figure...

[QUOTE=storm5510;531824]I looked around here today and I saw no mention of any program which could use the GPU in a Linux environment. I found that rather amazing. Perhaps I did not look where I should have. Is there no such animal?[/QUOTE]
Much of the gpu GIMPS app development was and is done on linux. Preda doesn't have Windows for building or testing. He leaves that to us. The readmes for mfaktc, CUDALucas, etc, mention linux.

[QUOTE=PhilF;532040]My personal experience is that they are one of the lower quality motherboard manufacturers as well.

However, someone please correct me if I am wrong, when it comes to Radeon VII GPUs George's experience is that the ASRock branded ones are giving the fewest problems. Go figure...[/QUOTE]

Again, the problem of small sample size. The ASRock GPUs have worked well, I did get one bad XFX GPU and one good one.

ASRock motherboards were used in "George's dream build". They worked well over the years. I used them because they discovered a way to overclock memory using a chipset that was supposed to prevent that. Free boost in throughput for me.

Now that I have Radeon VIIs, I've been torn about keeping the dream builds running. The dream build used 7 CPUs on one 1 power supply. It burns 450 watts. Compare that to a GPU which is about 40% more productive and uses only 250 watts.

In theory, if I could sell each of seven mobo/CPU/ram combos for $100, I could buy one Radeon VII instead and come out ahead. Don't know if that is unrealistic or worth the hassle.

[QUOTE=Prime95;532062]
In theory, if I could sell each of seven mobo/CPU/ram combos for $100, I could buy one Radeon VII instead and come out ahead. Don't know if that is unrealistic or worth the hassle.[/QUOTE]

I would buy a mobo/cpu/ram combo from you for $100; probably others on the forum would too.

Has the automated submission to [I]PrimeNet[/I] from [I]Colab[/I] been implemented? Based on my experience yesterday evening, it would seem so... :unsure:

[QUOTE=storm5510;532202]Has the automated submission to [I]PrimeNet[/I] from [I]Colab[/I] been implemented? Based on my experience yesterday evening, it would seem so... :unsure:[/QUOTE]Based on my experience of right now, I would say not, at least not for TF. Are you talking about mfaktc or mprime?

[QUOTE=storm5510;532202]Has the automated submission to [I]PrimeNet[/I] from [I]Colab[/I] been implemented? Based on my experience yesterday evening, it would seem so... :unsure:[/QUOTE]

Nope. I'm only now back to transition from the "limping" GPU72 server to the new one (with Toshiba HDs!).

I /was/ doing some clean-up last night, clearing out results which had been done by "Anonymous" TF Notebook runs. Is this what you're talking about? Or have I made (yet another) stupid administrator's error?

[QUOTE=chalsall;532205]Nope. I'm only now back to transition from the "limping" GPU72 server to the new one (with Toshiba HDs!).

I /was/ doing some clean-up last night, clearing out results which had been done by "Anonymous" TF Notebook runs. Is this what you're talking about? Or have I made (yet another) stupid administrator's error?[/QUOTE]

I believe he is talking about this:

[CODE]https://www.gpu72.com/account/colab/results/
.
.
This will be automated shortly... [/CODE]

[QUOTE=petrw1;532210]I believe he is talking about this:[/QUOTE]

Yeah... And then just about every system imaginable failed all at once... :cry:

[QUOTE=James Heinrich;532203]Based on my experience of right now, I would say not, at least not for TF. Are you talking about mfaktc or mprime?[/QUOTE]

[I]mfaktc[/I]. I tried to submit more today, manually, They were refused. [U]Result not needed[/U], it said.

[QUOTE=storm5510;532230][I]mfaktc[/I]. I tried to submit more today, manually, They were refused. [U]Result not needed[/U], it said.[/QUOTE]Look at your PrimeNet account results page. I submitted some manual results the other day [earlier this week] (a mix of Colab and mfakto on my integrated graphics chip). They were all marked as not needed, but shouldn't have been. Some were in the 200,000,000 range and I manually raised the assignment by an extra bit. I got the assignment via Prime95, moved them over to the mfakto worktodo, and change the 70,71 to 70,72 at the end of each line. Then I waited until it was done with 72 bits and submitted 71 and 72 at the same time.

I think it is a problem with PrimeNet's processing.

[QUOTE=chalsall;532205]I /was/ doing some clean-up last night, clearing out results which had been done by "Anonymous" TF Notebook runs.[/QUOTE] I noticed a bit of other clean-up happening.

[QUOTE=Uncwilly;532234]I submitted some manual results the other day... They were all marked as not needed, but shouldn't have been.
I think it is a problem with PrimeNet's processing.[/QUOTE]Both [i]Uncwilly[/i] and [i]storm5510[/i]: If you can identify a specific exponent for which this happened I can take a look and perhaps figure out why you got that message.

[QUOTE=James Heinrich;532239]Both [i]Uncwilly[/i] and [i]storm5510[/i]: If you can identify a specific exponent for which this happened I can take a look and perhaps figure out why you got that message.[/QUOTE]I am sending you a PM with my best guesses at some of the exponents in question.

[QUOTE=James Heinrich;532239]Both [I]Uncwilly[/I] and [I]storm5510[/I]: If you can identify a specific exponent for which this happened I can take a look and perhaps figure out why you got that message.[/QUOTE]

M94052807, M95431241, M95431309, M95432759, and M95435729. These five were submitted as a group from my notebook results page.

[QUOTE=Uncwilly]Look at your PrimeNet account results page...[/QUOTE]

They are all there, twice.

[QUOTE=storm5510;532245]They are all there, twice.[/QUOTE]

I don't see anything unusual in the GPU72 database. Single assignment, single results record in the ColabResults table.

Is there any chance you didn't wait long enough for the results to be "observed" by GPU72 (can take up to 30 minutes, depending on the range) before copy-and-pasting again?

[QUOTE=storm5510;532245][M]94052807[/M], [M]95431241[/M], [M]95431309[/M], [M]95432759[/M], and [M]95435729[/M]. These five were submitted as a group from my notebook results page. They are all there, twice.[/QUOTE]They are there twice, but not identically:
The first instance of each (submitted 18:18h) does not contain the UID portion, whereas the second instance (submitted 23:07h) does contain UID. This would seem to indicate that you copy-pasted the results from two separate places? Not that it should make any difference to the result being accepted with or without the UID, and with nearly 5 hours between the two submissions there should have been sufficient time for GPU72 to pick up the submission.

Let's see what insight Chris has.

[QUOTE=James Heinrich;532247]They are there twice, but not identically:
The first instance of each (submitted 18:18h) does not contain the UID portion, whereas the second instance (submitted 23:07h) does contain UID. This would seem to indicate that you copy-pasted the results from two separate places? Not that it should make any difference to the result being accepted with or without the UID, and with nearly 5 hours between the two submissions there should have been sufficient time for GPU72 to pick up the submission.

Let's see what insight Chris has.[/QUOTE]

It is entirely possible that I sent them twice. As for the UID's in the second group, I wrote a small program to pad this on the front of each line. Why? Things seem to be migrating to where they will be required.

[QUOTE=storm5510;532268]I wrote a small program to pad this on the front of each line. Why?[/QUOTE]But your [url=https://www.gpu72.com/account/instances/results/]Notebook Instance Results[/url] already have the UID at the beginning of the line... so where are you getting the without-UID lines from?

[QUOTE=James Heinrich;532270]But your [url=https://www.gpu72.com/account/instances/results/]Notebook Instance Results[/url] already have the UID at the beginning of the line... [/QUOTE]

ONLY where GPU72 knows the user's PNUN. In storm's case, GPU72 doesn't have this knowledge, so the UID information is not added.

[QUOTE=chalsall;532271]ONLY where GPU72 knows the user's PNUN.[/QUOTE]Perhaps if GPU72 doesn't know the user's PNUN, there should be a conspicuous prompt on the NIR page to say "please click here to update your profile with your PrimeNet User Name"?

[QUOTE=James Heinrich;532272]Perhaps if GPU72 doesn't know the user's PNUN, there should be a conspicuous prompt on the NIR page to say "please click here to update your profile with your PrimeNet User Name"?[/QUOTE]

Sure. Right after I build the page which let's one update their profile... :wink:

It's still in the queue; along with /many/ other things...

[QUOTE=chalsall;532273]It's still in the queue; along with /many/ other things...[/QUOTE]

It's a very good thing that you enjoy what you do... :smile:

[QUOTE=James Heinrich;532270]But your [URL="https://www.gpu72.com/account/instances/results/"]Notebook Instance Results[/URL] already have the UID at the beginning of the line... so where are you getting the without-UID lines from?[/QUOTE]

From my notebook results page on GPU72.com. They do not show them there and I will stop adding them to avoid the confusion. This field is very narrow and it might be truncating the userid/compid from the front. This is not a problem, as long as [I]PrimeNet[/I] accepts them. No fixes needed.

[QUOTE=chatsall]Sure. Right after I build the page which let's one update their profile... :wink:[/QUOTE]

I have been down this road. There is nothing like having too much on your plate. In your case, the plate is two feet in diameter.

[QUOTE=PhilF;532274]It's a very good thing that you enjoy what you do... :smile:[/QUOTE]

Thanks for that. Sincerely. And I /love/ what I do.

I learnt long ago that happiness is more important than money. I've actually walked away from six figure jobs because I wasn't having fun.

[QUOTE=storm5510;532279]They do not show them there and I will stop adding them to avoid the confusion. This field is very narrow and it might be truncating the userid/compid from the front. This is not a problem, as long as [I]PrimeNet[/I] accepts them. No fixes needed.[/QUOTE]The UID will show there (and there is plenty of room to display them, don't worry) as soon as Chris undergoes mitosis and finds time to add the feature to let you tell GPU72 your PrimeNet User Name.

[QUOTE=James Heinrich;532281]The UID will show there (and there is plenty of room to display them, don't worry) as soon as Chris undergoes mitosis and finds time to add the feature to let you tell GPU72 your PrimeNet User Name.[/QUOTE]

I run [I]Colab[/I] instances on my laptop. A good job for it. I will start one and see how they present in the results.

[QUOTE=storm5510;532283]I run [I]Colab[/I] instances on my laptop. A good job for it. I will start one and see how they present in the results.[/QUOTE]It will display without UID for the next [i]<unit_of_time>[/i]. See [URL="https://www.mersenneforum.org/showpost.php?p=532273&postcount=4494"]post #4494[/URL].

[QUOTE=James Heinrich;532284]It will display without UID for the next [I]<unit_of_time>[/I]. See [URL="https://www.mersenneforum.org/showpost.php?p=532273&postcount=4494"]post #4494[/URL].[/QUOTE]

"Until further notice," I believe would be a proper statement. As I wrote before, no problem.

Does a script/spider for getting TF and/or P1 assignments from GPU72 exist? I feel like it does... but I'm not sure.

[QUOTE=kracker;532474]Does a script/spider for getting TF and/or P1 assignments from GPU72 exist? I feel like it does... but I'm not sure.[/QUOTE]
Misfit should work for this.

[QUOTE=kracker;532474]Does a script/spider for getting TF and/or P1 assignments from GPU72 exist? I feel like it does... but I'm not sure.[/QUOTE]For P-1, if you set Prime95 to use GPU72 as a proxy then you'll get GPU72-assigned work. In Prime95 choose from the menu:
Test | PrimeNet | Connection
and then enter
host: gimps.gpu72.com
port: 80

Alternately, in prime.txt, set:[code][PrimeNet]
ProxyHost=gimps.gpu72.com:80[/code]

[QUOTE=Uncwilly;532477]Misfit should work for this.[/QUOTE]

:davieddy: Sorry, should have clarified... I was looking for a more "universal" thing(python/perl etc).

More specifically, I'm looking to see if I can automate P-1 assignments from GPU72 in colab with gpuowl.

[QUOTE=kracker;532483]More specifically, I'm looking to see if I can automate P-1 assignments from GPU72 in colab with gpuowl.[/QUOTE]

Mark Rose's [URL="https://github.com/MarkRose/primetools"]PrimeTools[/URL] would probably be your best starting point for a Linux / Agnostic solution.

I noticed a very minor issue: on the LL TF assignments page, the preview section will say "No assignments available which match your criteria" if I say I will factor to 74 bits. However, the server will still give me assignments.

[QUOTE=ixfd64;532509]However, the server will still give me assignments.[/QUOTE]

Yup. The preview function was actually an experiment in AJAX many years ago.

Completely different code paths. The UI is more along the lines of "this might be what you get; click submit to find out"... :wink:

It would appear the 2^74's are nearly done. I am getting assignments above 995xxxxx. If so, then we will definitely be treading into [I]Colab[/I] territory soon. I have one running 954xxxxx to 2^75.

[QUOTE=storm5510;532597]It would appear the 2^74's are nearly done. I am getting assignments above 995xxxxx. If so, then we will definitely be treading into [I]Colab[/I] territory soon. I have one running 954xxxxx to 2^75.[/QUOTE]

Yup. We're about three weeks or so from bringing most of 9x up to 74.

Thanks to Ben, the idea of giving LL Cat4 assignments which have been "optimally" TF'ed and P-1'ed has been thrown out the window.

No problem. Instead, super cool! :tu:

My current thinking is once everything in 99M is taken to 74, GPU72 will next offer work to take to 75 (starting in 95M). The next logical and least expensive work assignment which "Makes Sense" for GIM[B][U][I]P[/i][/u][/b]S in the near future.

Alternative thinking welcomed.

[QUOTE=chalsall;532675]Yup. We're about three weeks or so from bringing most of 9x up to 74.

Thanks to Ben, the idea of giving LL Cat4 assignments which have been "optimally" TF'ed and P-1'ed has been thrown out the window.

No problem. Instead, super cool! :tu:

My current thinking is once everything in 99M is taken to 74, GPU72 will next offer work to take to 75 (starting in 95M). The next logical and least expensive work assignment which "Makes Sense" for GIM[B][U][I]P[/I][/U][/B]S in the near future.

Alternative thinking welcomed.[/QUOTE]

Running 2^75's on Colab is not practical, for me. My 1080 can run around 3x what a K80 can. 2^74's, at this level finish in 29 minutes, typically. Double that for a 2^75. I have no problems with that. The only thing they have faster is a P100, and above. I never seem to get those now. So, I think I will let that part of this go.

I agree with your thinking on LL and P-1 here. Let the people who like to run those, run them, when they are factored enough. There is no need to mix them here!

I decided to give this a run today and I got something new, to me:

Tesla P100-PCIE-16GB

It's about the same speed as the previous P100. 1100 GHz-d/day. This would appear to have more RAM.

Every P100 I've seen says 16GB

[QUOTE=James Heinrich;532909]Every P100 I've seen says 16GB[/QUOTE]

Ditto. On Colab. And they're a recent addition.

Interestingly, out of the last four backend requests, three have been P100s.

I haven't run Kaggle for a while now, but I seem to remember they weren't explicit about the RAM. Could be wrong about that.

[QUOTE=James Heinrich;532909]Every P100 I've seen says 16GB[/QUOTE]

Until now, they have displayed as something shorter than what I wrote above. Perhaps it is just a name change and nothing more.

I think we have reached the top of the collection. I am receiving this error from [I]Gpu72WorkFetch[/I].

[QUOTE]Fatal Error: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: startIndex[/QUOTE]

I also got something (different) odd:[code]20191222_133834: GPU72 TF V0.33 Bootstrap starting...
20191222_133834: Working as "xxxxxxxxxxxxxxxxxxxxxxxx"...

20191222_133834: Installing needed packages (1/4)
20191222_133839: Installing needed packages (2/4)
20191222_133845: Installing needed packages (3/4)
20191222_133854: Installing needed packages (4/4)
20191222_133855: Fetching initial work...
20191222_133856: Running GPU type Tesla P100-PCIE-16GB

20191222_133856: running a simple selftest...
20191222_133900: Selftest statistics
20191222_133900: number of tests 107
20191222_133900: successfull tests 107
20191222_133900: selftest PASSED!
20191222_133900: Bootstrap finished. Exiting.[/code]Restarting the notebook results in the same thing.
My other instance happily resumed its work (I'll have to check in 30 mins if it continues to a next exponent or also quits).

Yes, I am receiving that as well, plus, there are no assignments allocated to crunch using Colab.

[QUOTE=James Heinrich;533364]I also got something (different) odd:[code]20191222_133834: GPU72 TF V0.33 Bootstrap starting...
20191222_133834: Working as "xxxxxxxxxxxxxxxxxxxxxxxx"...

20191222_133834: Installing needed packages (1/4)
20191222_133839: Installing needed packages (2/4)
20191222_133845: Installing needed packages (3/4)
20191222_133854: Installing needed packages (4/4)
20191222_133855: Fetching initial work...
20191222_133856: Running GPU type Tesla P100-PCIE-16GB

20191222_133856: running a simple selftest...
20191222_133900: Selftest statistics
20191222_133900: number of tests 107
20191222_133900: successfull tests 107
20191222_133900: selftest PASSED!
20191222_133900: Bootstrap finished. Exiting.[/code]Restarting the notebook results in the same thing.
My other instance happily resumed its work (I'll have to check in 30 mins if it continues to a next exponent or also quits).[/QUOTE]

My last Colab instance ran in the 95M area from 2^74 to 2^75. It did not seem to have a fetch problem at the time.

As for the rest, I was kind of expecting it to wrap back around on its own and start running everything again to 2^75. It never occurred to me that it would have to be reset manually, if that is what needs to happen.

[QUOTE=James Heinrich;533364]My other instance happily resumed its work (I'll have to check in 30 mins if it continues to a next exponent or also quits).[/QUOTE]After it finished its assignment it did indeed quit:[code]20191222_154800: no factor for M95828179 from 2^74 to 2^75 [mfaktc 0.21 barrett76_mul32_gs]
20191222_154800: tf(): time spent since restart: 17m 38.257s
20191222_154800: estimated total time spent: 50m 50.830s
20191222_154800: Bootstrap finished. Exiting.[/code]

Send Chris a PM. He can fix the problem.

Also, he posted code a while back about how to add assignments. Run the initial code. Let it exit. Then run the code to add manual assignments. Or edit the worktodo file while stopped.

[QUOTE=Uncwilly;533377]He can fix the problem.[/QUOTE]

Oh shoot! Sorry guys. Should now be fixed; now going to 75.

:thumbs-up:

I'm getting 75-bit assignments even though I specified 74 bits using the "will factor to" option.

[QUOTE=ixfd64;533441]I'm getting 75-bit assignments even though I specified 74 bits using the "will factor to" option.[/QUOTE]

Yes.

That's because there's no longer anything available from GPU72 to take to 74.

If you want such work, please get it directly from Primenet.

I see. It might be a good idea to make a note of it on the assignment request page.

I believe we are being jumped over. Four days ago, I received a first-time LL test on M102515453. It had been factored to 2^74. I checked the Work Distribution Map on [I]mersenne.org[/I]. There are over 3,000 LL's assigned above 100,000,000. Only 11 P-1's.

There are over 2,800 out for LL's from 95,000,000 to 99,999,999. I really do not understand why this is going on. I always thought a P-1 was an absolute must before running any first time test.

[QUOTE=storm5510;533753]I believe we are being jumped over.[/QUOTE]

Yup, I'm afraid so.

Currently, Cat 4 is up in the 102M range. In a week or so, Cat 3 will enter 100M. We're still looking OK for Cats 0 through to 2.

But if anyone has any GPU compute available (perhaps Santa was kind???) we could *really* use some more TF'ing firepower.

[QUOTE=storm5510;533753]I always thought a P-1 was an absolute must before running any first time test.[/QUOTE]

Is it still the case that if you get assigned a PRP or LL for an exponent that does NOT have P-1 that you will be assigned the P-1 first?

[QUOTE=petrw1;533791]Is it still the case that if you get assigned a PRP or LL for an exponent that does NOT have P-1 that you will be assigned the P-1 first?[/QUOTE]

My understanding is this a function within Prime95/mprime itself. If a P1 run wasn't done, it will be done first. Usually not terribly well, unfortunately, because of low RAM settings...

[QUOTE=chalsall;533798]My understanding is this a function within Prime95/mprime itself. If a P1 run wasn't done, it will be done first. Usually not terribly well, unfortunately, because of low RAM settings...[/QUOTE]

I run one of these occasionally as a hardware test. When the P-1 started, I thought something had gone wrong, so I stopped, and unreserved it. It is a DC that I normally run. Alzheimer's Lite kicked in, perhaps.

[QUOTE=chalsall;533771]Yup, I'm afraid so.

Currently, Cat 4 is up in the 102M range. In a week or so, Cat 3 will enter 100M. We're still looking OK for Cats 0 through to 2.

But if anyone has any GPU compute available (perhaps Santa was kind???) we could *really* use some more TF'ing firepower.[/QUOTE]
What I've got is currently LLTF 2x mfaktc on a GTX 1060 =~600-620 GHz-d/d. Lamentations for the loss of 115 GHz-d/d when the GTX 460 lost a fan. I wish I could drop something newer and badder in there. I have plenty of reserve in the PSU, but utterly destroyed discretionary spending, thanks to a couple of car parts going missing recently. :max: :mad: :sad:

Sell your 1060 and buy a 1650 / 1650 super

Bishop?
 

All of my mfaktc assignments are showing up in the GPU72 assignments report as assigned to a computer named "Bishop". I have no such machine.

[QUOTE=Chuck;533863]All of my mfaktc assignments are showing up in the GPU72 assignments report as assigned to a computer named "Bishop". I have no such machine.[/QUOTE]
I have one (a colab notebook) by that name. I tried to clear some manually assignments (that show up in my GPU72 assignments page) by dumping them into the woktodo file.

[QUOTE=Chuck;533863]All of my mfaktc assignments are showing up in the GPU72 assignments report as assigned to a computer named "Bishop". I have no such machine.[/QUOTE]

Ah, crap... Could you please PM me an example or two (exponent).

There have been no changes to any code, but this might be a "once a month" bug.

(Not meaning to gloat, but I just got home from watching fireworks with some friends; sitting on a beach in shorts and t-shirts, drinking fizzy wine and beers.)

Happy 2020 everyone!

[QUOTE=chalsall;533771]Yup, I'm afraid so.

Currently, Cat 4 is up in the 102M range. In a week or so, Cat 3 will enter 100M. We're still looking OK for Cats 0 through to 2.

But if anyone has any GPU compute available (perhaps Santa was kind???) we could *really* use some more TF'ing firepower.[/QUOTE]If you want help in TF, make it possible for non GPU72 to help. Leave some below 100M available to the rest of us to help TF without being part of GPU72. My gpu fleet is being forced to operate above 100M because it's not part of GPU72.

[QUOTE=Chuck;533863]All of my mfaktc assignments are showing up in the GPU72 assignments report as assigned to a computer named "Bishop".[/QUOTE][QUOTE=Uncwilly;533872]I have one (a colab notebook) by that name. I tried to clear some manually assignments (that show up in my GPU72 assignments page) by dumping them into the woktodo file.[/QUOTE]
[QUOTE=chalsall;533878]Ah, crap... Could you please PM me an example or two (exponent).

There have been no changes to any code, but this might be a "once a month" bug.[/QUOTE]
Seems fixed now for me.

[QUOTE=Uncwilly;533920]Seems fixed now for me.[/QUOTE]

Is there any chance you put a custom "Factor=" line into a Colab instance in the last day or so? Edit: Ah, I see that you said above that that's exactly what you did.

I /think/ what happened is you found a bug in my code; the ChkPoint code wasn't testing to see if the AID was blank, and so updated *everyone's* outstanding non-Colab assignments with your instance's CID.

Fixed.

[QUOTE=kriesel;533891]If you want help in TF, make it possible for non GPU72 to help. Leave some below 100M available to the rest of us to help TF without being part of GPU72. My gpu fleet is being forced to operate above 100M because it's not part of GPU72.[/QUOTE]

This is a bit tricky, in that Primenet will assign work sorted by P-1 desc, but not TF (grouped by 1M range).

I've just set things up such that GPU72 will now release at 76 bits in the Cat 2 and above ranges where P-1 has already been done. Several of our "big guns" who were working to 77 are now being giving work to 76.

I think it would be a good idea if George / Aaron set up Primenet such that Ben always got Cat 0 or 1.

I would welcome any other suggestions on how to deal with this situation.

[QUOTE=chalsall;533924]
I think it would be a good idea if George / Aaron set up Primenet such that Ben always got Cat 0 or 1.[/QUOTE]

All Ben's machines are Cat 1 eligible.

[QUOTE=Prime95;533929]All Ben's machines are Cat 1 eligible.[/QUOTE]

And yet I see *many* assignments in Cat 2; assigned as recently as 12.30. Is this a recent change?

[QUOTE=chalsall;533936]And yet I see *many* assignments in Cat 2; assigned as recently as 12.30. Is this a recent change?[/QUOTE]

No, been in place for months. I just looked at the "recent cleared" report and nearly all Ben's returned results are below 91M.

Not sure what assignments you are seeing and what their story is.

[QUOTE=Prime95;533941]Not sure what assignments you are seeing and what their story is.[/QUOTE]

Take a look at [URL="https://www.mersenne.org/assignments/?exp_lo=96000000&exp_hi=99000000&exdchk=1&exp1=1&extf=1"]this query[/URL], then search for "Ben Delo". Currently I'm seeing 91 assignments, all assigned within the last two weeks.

[QUOTE=chalsall;533948]Take a look at [URL="https://www.mersenne.org/assignments/?exp_lo=96000000&exp_hi=99000000&exdchk=1&exp1=1&extf=1"]this query[/URL], then search for "Ben Delo". Currently I'm seeing 91 assignments, all assigned within the last two weeks.[/QUOTE]

I mis-remembered. I wrote special server code that exempted Ben from mandatory first-time double-checks --- Amazon instances are super-reliable.

Since you think GPU72 will run more smoothly if his new instances are assigned cat 1, I've changed the get-assignment code to make that happen.

[QUOTE=Prime95;533952]Since you think GPU72 will run more smoothly if his new instances are assigned cat 1, I've changed the get-assignment code to make that happen.[/QUOTE]

Thanks, George.

And with regards to "run more smoothly", we're at a situation where LL Cat 3 and 4 are going to be given work seriously "sub-optimally" TF'ed, nor even P-1'ed. But many of those assignments are going to expire.

Cat 2 will be OK for another few months, getting work taken to at least 75, most likely 76 or even 77. We have enough of a buffer/firepower for Cat 1/0 for a good couple of years.

This is not the end of the world. It's "sub-optimal" for overall throughput, but rarely do we live in an optimal world.

And let's not forget: this is GIM[B][I][U]P[/U][/I][/B]S, not GIM[B][I][U]F[/U][/I][/B]S.

Thanks to Ben (et al), we're likely to find the next MP much sooner than previously estimated. :tu:

(Now if Ben would like to invest some GPU TF'ing firepower, that would be /really/ cool... :wink:)

Any chance GPU to 72 will start giving assignments above 100m soon? I'm starting to get LL assignments in the 100m range that have only been factored up to 74 bits.

[QUOTE=ixfd64;534300]Any chance GPU to 72 will start assignments above 100m soon? I'm starting to get LL assignments in the 100m range that have only been factored up to 74 bits.[/QUOTE]

Yeah... We really need to discuss this as a team, and figure out what's the best thing to do.

Basically, because of a certain individual, GIMPS LL throughput has more than tripled in the last three months (!). This is ***amazingly*** cool news! Thanks Ben!

However, this has completely messed with the goal of having all LL assignments "optionally" TF'ed, and P-1'ed (ideally "well", by P-1'ing "specialists").

Currently, it is "optimal" to TF to 77 "bits", but with the current TF'ing "firepower" we're only producing about 50 a day; to stay "steady-state" we would need to produce 900 a day!

We do have ~60,000 candidates already ready for LL assignment, but that's only going to last us two months. What I've currently got GPU72 doing is giving out work in such a way as we "chase" ahead of the Cat 2 assignments such that they are optimally TF'ed and P-1'ed. However, it won't take long until Cat 2 also gets into the 10xM ranges.

Then, I don't know... Should we start releasing at 75, hoping to occasionally get to 76?

And/or, should we bring in work in the 10xM ranges, and start bringing them up (many are still only at 72 bits).

I would really welcome suggestions as to what people want to see happen/thinks makes sense.

And, as always (but particularly now), if anyone has any GPU compute they could bring to bear, it would be much appreciated!

Thoughts?

[QUOTE=ixfd64;534300]Any chance GPU to 72 will start giving assignments above 100m soon? I'm starting to get LL assignments in the 100m range that have only been factored up to 74 bits.[/QUOTE]

[B]Ditto![/B]

In my humble opinion, This project should be doing [U]only[/U] TF work. P-1's and LL's should not be done here. Those should be reserved from [I]Primenet[/I].

:two cents:

[QUOTE=storm5510;534305] In my humble opinion, This project should be doing [U]only[/U] TF work. P-1's and LL's should not be done here. Those should be reserved from [I]Primenet[/I].[/QUOTE]

And that's pretty much the case currently.

For historical reasons, LL/DC work is available through a "proxy", but now-a-days it's simply a record-keeping function -- all work is actually fetched from Primenet.

P-1'ing is still available directly, but we only reserve a few hundred candidates at a time for that -- and in fact at a higher level (read: more computationally expensive) than what's available directly from Primenet.

[QUOTE=chalsall;534304]Yeah... We really need to discuss this as a team, and figure out what's the best thing to do.

Currently, it is "optimal" to TF to 77 "bits", but with the current TF'ing "firepower" we're only producing about 50 a day; to stay "steady-state" we would need to produce 900 a day!

Then, I don't know... Should we start releasing at 75, hoping to occasionally get to 76?

And/or, should we bring in work in the 10xM ranges, and start bringing them up (many are still only at 72 bits).
[/QUOTE]

Thinking out loud. If you took all the GPU72 firepower what bit level could produce 800-900 results a day? Make that your target.

I'm guessing that pre-Ben you thought GPU72 could stay ahead of the wavefront TF'ing to 2^77. Post-Ben we have 4x the LL/PRP power means you need to drop down 2 bit levels and make 2^75 your target.

I'd say bring in the some of the 10xM ranges and get them up to 2^74 at a minimum.

It is all so complicated!
1) The daily cat 1/2/3/4 thresholds are changing faster than they used to. If you TF the very smallest cat 4 exponents and they don't get assigned, they become the highest cat 3 exponents and won't get assigned for quite some time.
2) TFing the highest exponents nets the most savings, but cat 4 churn means you may have time to find a potential factor at a later date.
3) Optimal is to maintain a supply of decently TF'ed exponents at 4 wavefronts that are moving targets.

Don't worry that we reaching optimal TF levels. The DCTF group will have years to achieve that with much better GPUs.

[QUOTE=Prime95;534310]It is all so complicated! ...

Don't worry that we reaching optimal TF levels. The DCTF group will have years to achieve that with much better GPUs.[/QUOTE]

Yeah; that goal was abandoned some time ago... I only today "did the numbers" with current heuristics, and realized just how little time we have. (And, based on the [URL="https://www.mersenne.org/primenet/graphs.php"]graphs[/URL], Ben appears to continue to add "kit"! Wow!)

My current plan is to continue keeping Cat 2 fed as best we can until they're up into the 100M range. We have a reasonable buffer up in 99M to keep them feed, but as you note that is climbing surprisingly quickly.

Then we'll start getting 9xM ready to at least 75, and over the next couple of days I'll bring in some 10xMs to bring up as best we can.

One thing which might be helpful is if Primenet would assign work sorted by TF level desc (as with P-1, grouped by 1M range). That way GPU72 workers could focus on the high end of each range, as the wavefronts race towards us.

As always, feedback and suggestions greatly appreciated.

P.S. A real pitty Kaggle is completely out of commission, and Colab appears to be seriously constraining us...

We've lost some big TF users too.

The Judger...though he comes and goes
Air Squirrels
Flash JH
Jon Pace
LaurV ...maybe when he's back from Oz.
Ryan Propper


and a few others.

[QUOTE=petrw1;534315]We've lost some big TF users too. ... and a few others.[/QUOTE]

Yup. But even if they all returned, we still wouldn't be able to keep up with "optimal". As said before, this isn't the end of the world. And it does mean the next MP is going to be found /much/ sooner! :smile:

Oh, and just for the record, Jon Pace is continuing to contribute ~3.5 THzD/D of work.

[QUOTE=chalsall;534318]

Oh, and just for the record, Jon Pace is continuing to contribute ~3.5 THzD/D of work.[/QUOTE]

My bad

For what it's worth, my tf1G project throughput seems to have [url=https://www.mersenne.ca/tf1G#chart_div1]tanked since Dec 20[/url] (down by ~90%), so perhaps those who were applying resources there have redirected them to more (immediately) useful work such as is being discussed here. And I'm perfectly fine with that. :smile:

[QUOTE=chalsall;534312]One thing which might be helpful is if Primenet would assign work sorted by TF level desc (as with P-1, grouped by 1M range). That way GPU72 workers could focus on the high end of each range, as the wavefronts race towards us.[/QUOTE]

George: your thoughts on specifically this suggestion?

In my mind, there is little sense in GPU72 issuing work in 10xM unless this delta is done on Primenet. Otherwise, there is little hope in having work done even to 74 "bits" and having only that picked up by LL'ers without reserving everything in a 1M range.

Having GPU72 reserve everything would prevent Primenet from issuing TF'ing work itself which would then soon be issued to LL'ers; IMO, a bad idea. There are several people working directly with Primenet -- the two "workforces" should be cooperating here. GPU72 does some work at the high end of each 1M range; Primenet does the same.

In the short form: Primenet should "order by [TF Level] desc, [P1 done] desc group by [1M range]". My understanding is currently only the latter clause is in the query, which no longer has any real impact since almost no P-1'ing has been done at 100M and above.

Thoughts?

[QUOTE=chalsall;534344]George: your thoughts on specifically this suggestion?

In my mind, there is little sense in GPU72 issuing work in 10xM unless this delta is done on Primenet. Otherwise, there is little hope in having work done even to 74 "bits" and having only that picked up by LL'ers without reserving everything in a 1M range.

Having GPU72 reserve everything would prevent Primenet from issuing TF'ing work itself which would then soon be issued to LL'ers; IMO, a bad idea. There are several people working directly with Primenet -- the two "workforces" should be cooperating here. GPU72 does some work at the high end of each 1M range; Primenet does the same.

In the short form: Primenet should "order by [TF Level] desc, [P1 done] desc group by [1M range]". My understanding is currently only the latter clause is in the query, which no longer has any real impact since almost no P-1'ing has been done at 100M and above.

Thoughts?[/QUOTE]

As I understand The Math: [url]https://www.mersenne.org/various/math.php[/url]
specifically on the topic of TF, PrimeNet has already taken all exponents up to 190M to the prescribed limits;
that is, 1 bit below "The Math" page which then needs a P-1 before the last bit.

That said, I agree that a coordinated effort between GPU72 and PrimeNet is the best offense;
but I suspect for that to happen George would need to change the PrimeNet TF limit rules.

[QUOTE=petrw1;534346]As I understand The Math: [url]https://www.mersenne.org/various/math.php[/url] specifically on the topic of TF, PrimeNet has already taken all exponents up to 190M to the prescribed limits;[/QUOTE]

Those maths are from before GPUs entered the equation.

[QUOTE=petrw1;534346]...but I suspect for that to happen George would need to change the PrimeNet TF limit rules.[/QUOTE]

Nope. It would only be one (or only a few) changes to SQL statement(s). Include the "TF Depth" clause into the SQL query / sort statement(s). No other changes are needed.