mfakto: an OpenCL program for Mersenne prefactoring

[Dubslow]

Originally Posted by Rodrigo

Ah, your clue led me to this in UNDOC.TXT:

So if Dubslow is right, then I should add an AffinityScramble line to LOCAL.TXT (does it matter where?), and make it 01234567. What do you think?

Rodrigo

Like it says though, it should be automatically detecting and using that. Maybe it is better to set it manually, who knows. It's worth a shot, I think.

[kladner]

Originally Posted by chalsall

This is a known bug with the Primenet server -- memory starvation affecting the tool used to verify the factor.

Wait for George or Scott to reboot the server, or keep trying. Preferably not at the top of the hour -- wait until at least 15 minutes past.

I just emailed Scott. At the head of the Server Problems thread he states that he will notice emails much quicker than forum posts.

[Rodrigo]

Originally Posted by Dubslow

PrimeNet's having an "episode" right now.

Ohh, thanks for that. So I should wait a while and try submitting that result again. I should send both lines of the result, right?

Rodrigo

[Rodrigo]

Originally Posted by chalsall

This is a known bug with the Primenet server -- memory starvation affecting the tool used to verify the factor.

Wait for George or Scott to reboot the server, or keep trying. Preferably not at the top of the hour -- wait until at least 15 minutes past.

Thanks for the scoop, chalsall.

If donations to GIMPS went up, would it help them to prevent issues like this (by, say, getting newer or additional hardware?

Rodrigo

[chalsall]

Originally Posted by Rodrigo

If donations to GIMPS went up, would it help them to prevent issues like this (by, say, getting newer or additional hardware?

I have no knowledge of the financial situation of GIMPS, but there was talk earlier this year of upgrading the server. Additionally, two Linux geeks (James and myself) have offered to assist porting Primenet over to a LAMP stack, but that offer has not been pursued....

[Rodrigo]

Background:

Originally Posted by Rodrigo
So if Dubslow is right, then I should add an AffinityScramble line to LOCAL.TXT (does it matter where?), and make it 01234567. What do you think?

Originally Posted by Dubslow

Like it says though, it should be automatically detecting and using that. Maybe it is better to set it manually, who knows. It's worth a shot, I think.

OK, been running Prime95 with AffinityScramble2 set to 01234567, with the workers still set to Smart Assignment.

Everything seems to be running about as well as with Smart Assignment before adding the AffinityScramble2 line to LOCAL.TXT, the only difference being which CPU threads got selected for use by the three workers this time (the third, fifth, and seventh).

So I'm wondering if I can now uncheck CPUs "0" and "1" for Prime95 in Task Manager, and then specify mfakto to use, say, "0" for its work, as per flashjh's list upthread.

Rodrigo

[firejuggler]

AffinityScramble2, yeah, thats it

[kladner]

Originally Posted by kladner

I just emailed Scott. At the head of the Server Problems thread he states that he will notice emails much quicker than forum posts.

Scott has replied that "the manual results forms seem to encourage bulk processing activities that pound the server and starve-out most other users."

[chalsall]

Originally Posted by kladner

Scott has replied that "the manual results forms seem to encourage bulk processing activities that pound the server and starve-out most other users."

Now why, exactly, would a publicly facing web interface to a system be able to starve-out other users?

Might it be because of unnecessarily use of transactions?

[Rodrigo]

All right, I've been running Prime95 for some time now with Affinity unchecked in Task Manager for CPUs 0 and 1. With Smart Assignment and 2 threads per worker, the three P95 workers are keeping CPUs 2-7 each at or near 100% utilization. For some reason, the per-iteration times went up by 0.001-0.002 for each worker, but that may be a small price to pay to keep 'em to themselves (i.e., not spilling work over to the remaining core).

The next step will be to run mfakto on CPU 0 or 1 and see what happens. Given that the GPU load (according to GPU-Z) while I was running mfakto yesterday was only at 1%, I'm thinking of running two instances of mfakto off that first core ("CPUs" 0 and 1).

Rodrigo

[Rodrigo]

I've been fiddling with various affinity settings for mfakto (given the use of 3 cores on Prime95 and one on mfakto) with the following command:

start /low /affinity 0x1 mfakto-x64
start /high /affinity 0x1 mfakto-x64
start /affinity 0x1 mfakto-x64

None of these performed as well as when I didn't try to be so smart, and simply typed in:

mfakto-x64

With the first three, TF ETAs shot up to almost two hours, with time/class hovering at 6-7 seconds. With the last one, time/class is down to around 3 seconds. And yet, the system seems to have figured out all by itself that the unused first core is the one for mfakto to use. The per-iteration times on the three Prime95 cores were slightly affected (each suffering a hit of about 0.004 seconds; and none did any better with any of the start /affinity settings), but this is more than made up for by the vastly improved mfakto performance.

Rodrigo