ECM users - version 30.9/30.10 (see post#168)

[Luminescence]

736027 has a strange ECM result.

After finding a factor with the last curve of the assignment my client also reported a result with zero curves. I suspect it has to do with the ContinueECM setting (which I have enabled).

[LaurV]

Originally Posted by axn

That html is not coming from the program.

Obviously. It is the program who parses the reply in a wrong way.

(my upgrades were always "copy the new exe over the old exe, overwriting it, and never "whitelisted" anything - I mean, P95/PrimeNet related, they were never blocked, like faisbock or other traffic-causing, time-wasting sites )

[axn]

Originally Posted by LaurV

Obviously. It is the program who parses the reply in a wrong way.

It is the "reply" itself that is wrong (unexpected). Legitimate reply that comes from Primenet API doesn't look like that. I don't know where that html snippet is coming from - I was hoping that you would have some clue. Maybe use wireshark or something to capture the full response and figure out who/what/where of that? I could see some references for "access denied" in the snippet, which led me to believe something like firewall / VPN / proxy was causing the issue. But apparently you don't have any of that.

:-(

[Rubiksmath]

I've downloaded this (30.9b3) and been using it for a couple weeks, its a big improvement over the previous stage 2, although given that its like pre-beta there are some minor inconveniences. I find that with 4 workers the program doesn't split the RAM evenly and thus I will end up with really inconsistent B2 values, which you can see from my recent results line:

[Sat Nov 26 01:41:44 2022]
{"status":"NF", "exponent":222059, "worktype":"ECM", "b1":1000000, "b2":521770382, "curves":100, "fft-length":12288, "security-code":"1AF5DF55", "program":{"name":"Prime95", "version":"30.9", "build":3, "port":4}, "timestamp":"2022-11-25 15:41:44", "user":"Rubiksmath", "computer":"goodpc"}
{"status":"NF", "exponent":220841, "worktype":"ECM", "b1":1000000, "b2":2054030055, "curves":100, "fft-length":12288, "security-code":"7FA44DB2", "program":{"name":"Prime95", "version":"30.9", "build":3, "port":4}, "timestamp":"2022-11-25 15:42:18", "user":"Rubiksmath", "computer":"goodpc"}
{"status":"NF", "exponent":221453, "worktype":"ECM", "b1":1000000, "b2":588654775, "curves":100, "fft-length":12288, "security-code":"26FB626C", "program":{"name":"Prime95", "version":"30.9", "build":3, "port":4}, "timestamp":"2022-11-25 15:42:32", "user":"Rubiksmath", "computer":"goodpc"}
{"status":"NF", "exponent":220447, "worktype":"ECM", "b1":1000000, "b2":2359600110, "curves":100, "fft-length":12288, "security-code":"8977EEA0", "program":{"name":"Prime95", "version":"30.9", "build":3, "port":4}, "timestamp":"2022-11-25 15:46:17", "user":"Rubiksmath", "computer":"goodpc"}

I have to offset the workers a bit to prevent a crash, in my situation I've given ECM a max RAM usage of 14 GB, the first worker usually takes 10 GB of that when it reaches stage 2, the second then takes most of the remaining 4, leaving about 100MB left, and if another worker reaches stage 2 it will take most of the remaining 100MB and chances start to get very high of a crash, so I try my very best to offset the workers enough to prevent that. Interestingly, maybe this is just a me problem because in Anton Repko's recent ECM results he had identical B2 values, don't know if that is due to only using 1 worker or having more RAM (once I actually did get identical B2 for all 4 workers but I don't know why or how). Also, stopping a worker during stage 2 init is a guaranteed crash, and stopping a worker during stage 2 in general has a high enough crash chance that I get nervous when I have to do it. Maybe these are just me problems, its workable still but as I said for me at least requires careful management of my workers, and I guess it is a bit annoying when I wake up to check the results and find that it crashed only 5 minutes after I left it to run overnight lol, but with trial and error I have reduced the chances of that to <10%.

[James Heinrich]

Originally Posted by Rubiksmath

I find that with 4 workers the program doesn't split the RAM evenly

Easy solution: run 1 worker with 4 threads with full amount of RAM. Obviously full use of RAM will only happen roughly half the time, but more RAM is for stage2 when it runs.

Alternate solution: Allocate a fixed RAM amount per worker, and limit number of high memory workers.

Originally Posted by local.txt

MaxHighMemWorkers=3
[Worker #1]
Memory=4800
[Worker #2]
Memory=4800
[Worker #3]
Memory=4800
[Worker #4]
Memory=4800

It won't have more than 3 workers in stage2 at once, with a maximum of ~14GB used in that case.

[Rubiksmath]

Okay, thanks, I did not know you could limit the memory per worker, will try this.

[Rubiksmath]

Hmm, I copy-pasted that into local.txt but now each worker only thinks there is 1031MB of available memory, clearly I've goofed something up? also local.txt is now generating a bunch of duplicate settings (like 3 different computer GUID entries and a cores per test for each worker) so uh I guess I did a bad?

[James Heinrich]

Show us your whole local.txt ?

[Rubiksmath]

Ah I fixed it, turns out deleting the worker tags in local.txt and putting them elsewhere causes problems. Transferring those lines to the bottom of the file where the worker tags are to begin with did the trick. I could run 1 worker on 4 threads for guaranteed high and fast stage 2 but it doesn't help with stage 1 so I think it's best for me to still run 4 workers to get the most curves and work done.

[Rubiksmath]

Okay well still a minor thing but I still cannot get consistent B2, here is a sample worker window output (all merged):

[Worker #4 Nov 28 11:06] Stage 1 complete. 13605520 transforms, 1 modular inverses. Total time: 180.985 sec.
[Worker #4 Nov 28 11:06] Available memory is 5200MB.
[Worker #4 Nov 28 11:06] Optimal B2 is 1562*B1 = 1562000000.  Actual B2 will be 1562145585.
[Worker #4 Nov 28 11:06] Estimated stage 2 vs. stage 1 runtime ratio: 0.333
[Worker #4 Nov 28 11:06] Using 4093MB of memory.  D: 30030, degree-2880 polynomials.  Ftree polys in memory: 11
[Worker #4 Nov 28 11:06] nQx complete.  Time: 1.148 sec.
[Worker #4 Nov 28 11:06] PolyR built.  Time: 1.226 sec.
[Worker #4 Nov 28 11:06] Poly compress.  Time: 0.183 sec.
[Worker #4 Nov 28 11:06] Stage 2 init complete. 169890 transforms, 1 modular inverses. Time: 5.646 sec.
[Worker #1 Nov 28 11:07] Stage 1 complete. 19756886 transforms, 1 modular inverses. Total time: 269.410 sec.
[Worker #1 Nov 28 11:07] Available memory is 5200MB.
[Worker #1 Nov 28 11:07] Optimal B2 is 2054*B1 = 2054000000.  Actual B2 will be 2054030055.
[Worker #1 Nov 28 11:07] Estimated stage 2 vs. stage 1 runtime ratio: 0.392
[Worker #1 Nov 28 11:07] Using 4923MB of memory.  D: 43890, degree-4320 polynomials.  Ftree polys in memory: 8
[Worker #1 Nov 28 11:07] nQx complete.  Time: 1.777 sec.
[Worker #4 Nov 28 11:07] PolyG built.  Time: 3.091 sec.
[Worker #4 Nov 28 11:07] PolyH built.  Time: 1.507 sec.
[Worker #4 Nov 28 11:07] PolyG built.  Time: 3.161 sec.
[Worker #1 Nov 28 11:07] PolyR built.  Time: 2.103 sec.
[Worker #4 Nov 28 11:07] PolyH built.  Time: 1.484 sec.
[Worker #1 Nov 28 11:07] Poly compress.  Time: 0.301 sec.
[Worker #1 Nov 28 11:07] Stage 2 init complete. 260357 transforms, 1 modular inverses. Time: 8.937 sec.

(removed unrelated output from this excerpt for readability)
in this case worker 4 took less RAM, but on a previous test of this it used 4969MB RAM of the available 5200 yet still chose lower B2 (I think it was the same one chosen here). In this case worker 4 was running M222197, worker 1 was running M220793. To my knowledge they are running the same FFT length, is the difference in exponent size the cause or is something else at play here?

[LaurV]

P95 30.9 build 3, i7-6950X, win7, 48G RAM allocated (from 64), 1 worker 10 cores.

ECM doesn't like the exponent 2859071.

Seriously!

All exponents around it, work well, it takes minutes to stage 1 and minutes to stage 2 (see my daily result reports).

For this particular exponent stage 1 works well, but then stage 2 is stuck somehow.

Long story, I have seen no reports for a day or two and had to dig into this computer. This computer mines on GPUs and peeninetyfives ( I invented a verb!) on CPU. Mining I could see online in the pool, was fine, so it wasn't crashed, but P95 was doing stage 2 of the incriminated, with 3-5% of CPU resources used (usually, 48% CPU in stage 2).

Stopped, erased temp files, start again, stage 1 pufffff gone, normal time, minutes. Then, stage 2 started and locked locked, CPU usage went down shortly after.

Repeat few times, same result. I will move it to a different computer later, to see if it is settings-related.

Stopped again, put a semicolon in front of this line in worktodo file, everything works normally ever since (few days, no time to post till weekend). The line still there, with semicolon