[QUOTE=Prime95;568104] Those N freed temporaries will be needed again if another pooled modular inverse is required which is why prime95 won't let other threads reserve that memory.
[/QUOTE]

Thanks for the explanation. If I got it right, there are chunks of memory that are actually free, and perceived as such by Task Manager, but that are "set aside" by Prime95 on a just in case basis. Does that explain the difference between the amount of memory allowed to be used and the amount reported by TM (10 GB and 7.5 GB respectively)?

If I remember correctly, nordi´s problem was that the program was using more than its allowed share of memory, and the system would eventually crash under some circumstances. Now the opposite is apparently happening: the program is using less memory than it might do. I personally never had that problem with build 3. The program would use exactly the maximum amount of memory allowed (at least that was the indication in TM).

[QUOTE=lycorn;568106]Thanks for the explanation. If I got it right, there are chunks of memory that are actually free, and perceived as such by Task Manager, but that are "set aside" by Prime95 on a just in case basis. Does that explain the difference between the amount of memory allowed to be used and the amount reported by TM (10 GB and 7.5 GB respectively)?[/quote]

Yes, the 2.5GB would be needed if each worker in stage 2 ECM needed to do another pooled modular inverse at the same time.

[quote]If I remember correctly, nordi´s problem was that the program was using more than its allowed share of memory, and the system would eventually crash under some circumstances. Now the opposite is apparently happening: the program is using less memory than it might do. I personally never had that problem with build 3. The program would use exactly the maximum amount of memory allowed (at least that was the indication in TM).[/QUOTE]

Yes, I was unable to replicate nordi's case where prime95 was allocating 100GB rather than 50GB maximum nordi had set. This change (I can't call it a fix) should at least prevent the crash he was seeing, because it is unlikely that every ECM stage 2 will be doing a pooled modular inverse at the same time.

2080Ti GPU slowed about 3% after 30.4 Upgrade
 

Any ideas how/why this might have happened?

Running mfaktc.

[QUOTE=petrw1;568123]Any ideas how/why this might have happened?

Running mfaktc.[/QUOTE]

Heat? Could Cpu/Ram/Mobo running hotter now lead to GPU throttling itself a little?

I would suspect more along the lines of either CPU or RAM being more heavily utilized in v30.4 causing a small amount of extra delay in what little off-GPU resources mfaktc needs to use.

You seem to be both correct
 

GPU-Z had the GPU running a couple degrees hotter than usual (85C).
And some Therm throttling.
I blew out the dust and opened the side door.

It's running 83C now and a little faster but still not quite what it was before 30.4
Maybe 1% down (that's pretty close).

Woohoo!

I've conquered nordi's memory problem even though I may not fully understand it. I was able to replicate on my 8-core Skylake box. The problem is with ECM on tiny numbers. Prime95 is not properly estimating the space consumed allocating a gwnum. In 30.4b4 the estimate was 640 bytes. Careful examination of the code shows that 680 bytes plus any malloc overhead is required. My testing seems to indicate malloc overhead is much worse in Linux than Windows.

Furthermore, the (up to) 250MB prime pairing bit array was not included in prime95's memory reservation system.

To fix nordi's issue, I've limited prime95 to 100000 temporaries per worker. This should have no impact on performance. Prime95 was allocating over 1M temporaries to reduce modular inverses which are lightning fast on M1277.

In implementing the fix, I noticed a bug in resuming an ECM run in stage 2 when there is less memory available. This could well explain petrw1's missed factor when prime95 did a restart with new memory settings.

Does GmpEcmHook=1 still work for running stage 2 on GMP-ECM?

Is it still worthwhile to do so on exponents such as M1277?

[QUOTE=PhilF;568189]Does GmpEcmHook=1 still work for running stage 2 on GMP-ECM?[/quote]

It ought to.

[quote]Is it still worthwhile to do so on exponents such as M1277?[/QUOTE]

Most definitely.

[QUOTE=Prime95;568150]In implementing the fix, I noticed a bug in resuming an ECM run in stage 2 when there is less memory available. This could well explain petrw1's missed factor when prime95 did a restart with new memory settings.[/QUOTE]
Does the bug affect P-1 as well? Because that was a P-1.

[QUOTE=axn;568208]Does the bug affect P-1 as well? Because that was a P-1.[/QUOTE]

Yes. Until the next build is ready, avoid restarting P-1 or ECM in stage 2 with less memory.