[QUOTE=Uncwilly;538961]I have been seeing the same thing as James has been reporting, with the same fix. I have been ill the past few days and haven't felt like posting.[/QUOTE]

OK, thanks for the data. I can see from the logs that James' is not alone.

So, for anyone who launches the GPU72_TF payload and it stops after the mfaktc self-test, please curse in my general direction and then click Run again.

This has actually helped beat up the CPU payload resiliency. Each running instance should be devoting 100% of the CPU towards a single P-1 work unit at a time, no matter how many times the Section is restarted.

Thanks for all the patience with this, and all the compute! :smile:

P.S. And, of course, the exit is a profoundly stupid error by yours truly. The Bootstrap should loop if it runs out of work! Why ever exit? Death before exit!!!

[QUOTE=chalsall;538900]Yeah... I'm going to have to figure out how to have it *not* do that.

What is happening is the mprime process is getting "new settings" from the Primenet server (through the GPU72 proxy). I need to intercept those messages and ensure the running client doesn't see any changes. Rather wasteful having it stop and restart, particularly during Stage 2...

And, indeed... Please let us know how long your CPU-only session lasts.[/QUOTE]

My CPU only session ended after 24 hours and 1 minute (paid tier).

[QUOTE=chalsall;538963]OK, thanks for the data. I can see from the logs that James' is not alone.

So, for anyone who launches the GPU72_TF payload and it stops after the mfaktc self-test, please curse in my general direction and then click Run again.

This has actually helped beat up the CPU payload resiliency. Each running instance should be devoting 100% of the CPU towards a single P-1 work unit at a time, no matter how many times the Section is restarted.

P.S. And, of course, the exit is a profoundly stupid error by yours truly. The Bootstrap should loop if it runs out of work! Why ever exit? Death before exit!!![/QUOTE]

I just had three sessions exit after 24 hours each. All three needed the second restart to get going again.

Found a factor with 4th P1 exponent :)

[QUOTE=bayanne;539008]Found a factor with 4th P1 exponent :)[/QUOTE]

Excellent!

Just to share... It was kinda cool watching George use my code to run his (and Oliver's) code in a donated Colab instance, and for him to find a factor during his very first P-1 run!!!

I don't believe in luck; it's just statistics. I do, /kinda/, believe in karma, though... :smile:

Is this (zero exponent and stage) expected output at the end of stage1?
It seems to progress to stage2, I've just not paid attention before to the display at the transition.[quote]20200307_015640: [color=green]100968617 P-1 77 99.73% Stage: 1[/color]
20200307_015647: 102442429 73 to 74 52.1% 7m32s 1709.74 0.983s | 2412/4620, 500/960 | 9.98G | 10150.4M/s | 82485 | 1:58
20200307_015736: [color=green][b]0 P-1 77 Stage: 0[/b][/color]
...
20200307_021530: 102226979 73 to 74 70.8% 4m36s 1706.40 0.987s | 3264/4620, 680/960 | 10.00G | 10130.6M/s | 82485 | 2:16
20200307_021601: [color=green]100968617 P-1 77 3.13% Stage: 2[/color][/quote]

Too many active sessions
 

At least once a day I only get 1 session.
I start the tunnel... 1 session.
Can't start actual run.

[QUOTE=James Heinrich;539058]Is this (zero exponent and stage) expected output at the end of stage1?
It seems to progress to stage2, I've just not paid attention before to the display at the transition.[/QUOTE]
That happens during the GCD run. I have noticed them too. Chris forgot to anticipate that.

[QUOTE=petrw1;539059]At least once a day I only get 1 session. I start the tunnel... 1 session. Can't start actual run.[/QUOTE]

Of my seven accounts (spread across three machines in two countries) I'll often only get one or two GPU instances. I've yet to not be given a CPU session.

This morning at 1200 UTC I've not been given a single GPU. And not many people are running the GPU72_TF Notebook at the moment.

Just for clarity... When you say you "start the tunnel", are you running InstanceROOT reverse tunnels first? This should have no impact on anything, but I want to understand your context for debugging modeling.

[QUOTE=Uncwilly;539061]That happens during the GCD run. I have noticed them too. Chris forgot to anticipate that.[/QUOTE]

I didn't /forget/ exactly. Just busy... I need to finish off the regex filtering/transforms. Humans come after the kit... :wink:

I'm reworking the output for both the GPU and CPU contexts, to make them more compatible, cleaner and more informative. Also, to turn off all the deep debugging and multiple timestamps!

Some eye candy...
 

Hey all.

So, in my spare time I've been experimenting with the D3 Javascript graphing package. I thought some of you might be interested in one of the results...

If you click on the new links in the Range column in the [URL="https://www.gpu72.com/reports/available/"]available report[/URL], you'll be taken to a chart of the TF level of that 1M range. There are links from this page that lets you drill down to see all unfactored candidates, DC candidates, and those DC'ed but not factored.

For example, [URL="https://www.gpu72.com/charts/tf/dc/98/"]this chart of the 98M range[/URL] shows that almost all FC runs were done after TF'ing to 77.

Data (and databases) are fun!!! :smile:

P.S. These charts are rather crude, and don't (yet) scale to the window size. They're designed for 1920 pixel displays.