[QUOTE=James Heinrich;530528]Noting, however, that there's currently a (significant) disagreement between my calculus and what Prime95 (the program) selects as bounds. Presumably this is an error on my part, but I'm waiting to hear back from George on his take on the discrepancy.[/QUOTE]Thanks to George for pointing my brain back in the right direction. The bounds calculated on the P-1 probability calculator should be sane now. Let me know if they appear otherwise.

[QUOTE=James Heinrich;530559]...be aware that if you're requesting assignments via GET then you need to specify only one of ([I]max_assignments[/I] | [I]max_ghd[/I]), the latter will override the former if both are present....[/QUOTE]

Remember, this is for my laptop. No GPU. I did this manually on your request page. It seemed to want something in both of those boxes; putting a red outline on the GHz days box if there was nothing in it. I could modify one of my batch files to do this. I would have to leave everything out but the fetch part and trigger it when I need to. No loop back.

To my knowledge, there is not an option which will cause [I]Prime95[/I] to automatically unload itself when it runs out of work. There may be some little gimmick in Windows which could unload it from a batch process If there is, then I could run it like [I]mfaktc[/I] less-classes. This would need to be done by determining the current size of the [I]worktodo[/I] file. Just a few bytes in length, then kill it. The batch would then continue.

I set it to manual communication to prevent it trying to send the results to [I]PrimeNet[/I]. I suppose this is a test, of sorts. I don't know if I would want to run it all the time like this. Being a laptop, I generally rest it after three days of running so I can unplug it

[QUOTE=storm5510;530581]It seemed to want something in both of those boxes; putting a red outline on the GHz days box if there was nothing in it.[/quote]That shouldn't be. What browser are you using?

[QUOTE=storm5510;530581]To my knowledge, there is not an option which will cause [I]Prime95[/I] to automatically unload itself when it runs out of work.[/QUOTE]Such an option was [url=https://www.mersenneforum.org/showpost.php?p=529677&postcount=399]recently added to mprime[/url], but I don't think there is an equivalent option for Windows.

It's your hardware, but I would suggest that TF'ing with a laptop is perhaps not the best idea, it would spend many hours of hard-on-the-hardware work to get done what a GPU could do in a few minutes.

[QUOTE=James Heinrich;530583]That shouldn't be. What browser are you using?

It's your hardware, but I would suggest that TF'ing with a laptop is perhaps not the best idea, it would spend many hours of hard-on-the-hardware work to get done what a GPU could do in a few minutes.[/QUOTE]

Browser: Mozilla Firefox.

I have already stopped it. I will finish what it has on a GPU. :smile:

Just found-and-fixed another case where it might've returned an unexpected number of assignments.

[QUOTE=James Heinrich;530623]Just found-and-fixed another case where it might've returned an unexpected number of assignments.[/QUOTE]

This 60,000 I received, I've been sending them back in groups of around 2,500, give or take a little. They are in the 3700M area. I have a bit over 15,000 left to run.

[QUOTE=James Heinrich;530583]...It's your hardware, but I would suggest that TF'ing with a laptop is perhaps not the best idea, it would spend many hours of hard-on-the-hardware work to get done what a GPU could do in a few minutes.[/QUOTE]

Just a short follow-up. I have found a very good use for my laptop. I have two [I]Google Colaboratory[/I] instances which I alternate between, allowing each to age 24 hours, or more. This is monitoring a remote process so there is no excessive heat or undue stress anywhere. This is far better than what I was trying to do.

[QUOTE=James Heinrich;528460]Thanks. I had your effort recorded from 2800M-2999M but not the 3000M-3229M range. I have updated my data now.[/QUOTE]

I will now continue with this project, at least for now with a two-pronged approach. One machine continues from 3230M and goes up, until it eventually reaches 2¨32, after that it's down from 2800M. Another machine started from 1000M on up. And they'll meet at some point in time, some months in the future. But I'll keep you updated on the progress.

[QUOTE=nomead;530977]I will now continue with this project, at least for now with a two-pronged approach. One machine continues from 3230M and goes up, until it eventually reaches 2¨32, after that it's down from 2800M. Another machine started from 1000M on up. And they'll meet at some point in time, some months in the future. But I'll keep you updated on the progress.[/QUOTE]Just to refresh my memory, and make sure we're all on the same page, please describe what you're doing and your workflow (factoring from where to where, submitting what results and how often.

[QUOTE=James Heinrich;530990]Just to refresh my memory, and make sure we're all on the same page, please describe what you're doing and your workflow (factoring from where to where, submitting what results and how often.[/QUOTE]

I'm factoring bit levels 2 to 64 with mfaktc, and Stages=0 plus StopAfterFactor=0. I'm doing this for all prime exponents, checking against the database exports, and submitting only the remaining factor found results manually and semi-irregularly, one "chunk" at a time. This chunk happens to be everything within a million of the starting point (same four numbers in the beginning of the exponent). The checking is automated, I just need to run the submit script manually. But I try to submit at least once a day to avoid a big pileup in the submission queue.

[QUOTE=nomead;530994]submitting only the remaining factor found results manually and semi-irregularly, one "chunk" at a time.[/QUOTE]Thanks. I also need to manually update the how-far-fully-factored flag for the exponents you've thoroughly checked, if you could send me an email every so often (once a week, once a month, whatever) letting me know what ranges are completed I can run the update.