GPU to 72 status...

[Dylan14]

One thing I noticed on the View Assignments page is that the checkbox that is used to extend/release assignments only appears on non-Colab assignments. Is this an intentional thing, or is that a bug?

[chalsall]

Originally Posted by Dylan14

Is this an intentional thing, or is that a bug?

Intentional.

There's a bit of additional back-end stuff associated with a Colab assignment, so rather than writing the code which deals with that in the case of deletions I just don't let people delete.

This assumes that people will regularly connect with Colab to complete assignments. Those which have been abandoned (read: more than a week or so old) I just move over to my own account to finish off.

[LaurV]

Originally Posted by chalsall

I just move over to my own account to finish off.

Do you also give them the credit? If they did 57 classes from 960, and you do the rest, you should give them 5.93% of the credit...
(see how you explain that to google, and to primenet, hihi)

[Chuck]

For the last day my notebook results have not been auto-submitted. I've done two manual submissions so far.

[chalsall]

Originally Posted by Chuck

For the last day my notebook results have not been auto-submitted. I've done two manual submissions so far.

There was a bit of a weird cert problem on Mersenne.org yesterday, so I turned off a bunch of the spiders while Aaron worked the issue. Forgot to turn the submission spider back on.

[Chuck]

Originally Posted by chalsall

There was a bit of a weird cert problem on Mersenne.org yesterday, so I turned off a bunch of the spiders while Aaron worked the issue. Forgot to turn the submission spider back on.

Thanks. Working fine again.

[storm5510]

Just in case anyone might be interested, below is my Misfit workaround batch file. Misfit itself, gave me some real problems so I stopped using it. The batch file only reserves. It does not submit results. This would need to be done manually. Even so, it keeps the process running.

@echo off

rem Auto fetch from GPU72.
rem Press Ctrl-C to stop batch.
rem Restart mfaktc-2047 manually
rem to complete assigned work, if any.

:top
cls
call mfaktc-2047.exe
timeout 2

if exist c:\mfaktc\GPU72FETCH_logs\*.html (
    del c:\mfaktc\GPU72FETCH_logs\*.html
)

call c:\gpu72\gpu72workfetch c:\gpu72\gpu72config.txt
if %errorlevel% gtr 1 goto errHandler
echo.
goto top
:errHandler
timeout 60
goto top

Note the use of the "call" statement. This returns control to the batch file once the following process is complete. The "GPU72" folder was a leftover. It contains all the binaries needed to complete the fetch. I gave mfaktc the custom name to distinguish it from older versions which I cannot run on one of my machines. This batch needs to reside in the same folder as mfaktc.

The contents of the GPU72 folder are in the attached zip archive. The contents of GPU72config.txt will need to be edited to add credentials and make other changes, if needed.

[chalsall]

Hey all.

OK, because of some very cool work by Mihai, George, et al we need to rethink where the "optional" TF'ing level is. Basically, we will soon be at the point where DC'ing will no longer be needed to verify that a Candidate is composite.

This means that instead of a factor-finding TF'ing run saving two LL tests, it instead will only be saving one (plus the much less expensive Cert run).

So, instead of GPU72 targeting 77 bits (we should really have been going to 78), we'll soon start releasing at 76. This should be approximately "optimal" according to James' economic cross-over analysis charts. (Although some cards should still be going higher, such as Compute v7.5 kit.)

Because the transition to the VDF versions of Prime95 etc will take a while, and because I like things to be neat, I'd like to finish taking 9xM up to 77 bits (only ~5,600 to go). For the 10xM and 11xM ranges, we'll release at 76 when the demand requires it.

To be honest, this comes at a very timely moment. Ben is screaming through the candidates, and it looked like we'd need to start releasing sub-optimally anyway.

Also, tangentially... Although Reb and KEP demonstrated empirically that BOINC could provide a serious amount of GPU resources, I simply haven't had the time to take the GPU72 BOINC system past alpha. I've been dragged into a huge and mission-critical project which will prevent me from doing anything but maintenance on GPU72 until at least November. (Can't talk about it yet; I can't even count on one hand how many NDA's I'm under.)

Lastly... While we're now under less of a crunch, we could still use some more TF'ing firepower to build up a bit more of a buffer to 76 bits. Anyone who has any GPUs they might throw our way, it would be appreciated (even if only going to 74 or 75).

Or, for those doing the GPU72 TF Colab Notebook thing, if you're running less than four accounts, perhaps consider creating a few more (and/or, if you're in the USA, consider spending the $10 a month for the Pro access (much cheaper than buying your own kit))...

Thoughts? Comments? Suggestions?

And, as always, thanks for all the cycles everyone!

[VBCurtis]

Originally Posted by chalsall

....
So, instead of GPU72 targeting 77 bits (we should really have been going to 78), we'll soon start releasing at 76. .....

Thoughts? Comments? Suggestions?

And, as always, thanks for all the cycles everyone!

If we previously really should have been going to 78, shouldn't we now reallyshould go to 77? The LL test work is not quite cut in half because of CERT work, so we should move down less than one bit. Combine with exponent range increasing to 10xM from 9xM, and it seems like changing nothing might be closest to optimal?

Or is the need to keep the queue fed too great to have the luxury of TF77?

[chalsall]

Originally Posted by VBCurtis

If we previously really should have been going to 78, shouldn't we now really should go to 77? The LL test work is not quite cut in half because of CERT work, so we should move down less than one bit.

Nope. Where James shows we should be going for DC (the yellow/orange line) is now where we should be going for VDF tests. Remember that James' analysis includes the percentage of triple tests needed.

Originally Posted by VBCurtis

Or is the need to keep the queue fed too great to have the luxury of TF77?

Basically.

I had modeled that I would have the GPU72 BOINC system online in time, but then this project was dumped on me. (As usual, I was brought in when it was already in crisis; impossible (but politically unmovable) deadline...)

[James Heinrich]

Originally Posted by VBCurtis

The LL test work is not quite cut in half because of CERT work, so we should move down less than one bit.

Actually I think it might be slightly better than that. I believe the current assumption is that a DC costs 105% the first test (same effort but 1:20 will need a triple-check). If I read the numbers right a 1st-time PRP needs 100.2% and the check on the cert is 0.2%, perhaps 0.205% if we need TC. If that holds then LL = 205% and PRPcert = 100.4% = 0.4898 LL
I'm ignoring the possibility that the original PRP might be wrong and need redoing, I'm not sure if that's likely with the current error checking(?). I suppose it might be, but that pushes up back to ~0.5, at least close enough not to worry about the difference.

But, also bear in mind that while this is an exciting new idea, it's not quite yet implemented, and even when George/Mihai get out of testing and publish their updated software a large bulk of the installed base will be running old versions of Prime95/etc, it will take years before this becomes the dominant calculation.

As always, I expect the target bitlevel will be more influenced by available TF firepower than what is mathematically "optimal".