Tweaked assignment rules

[Prime95]

Effective today:

1) V4 clients will no longer be given first-time tests. If they request first-time tests they will be given double-checks. The theory is these machines are at least 2 years old and will struggle with first-time tests.

2) V4 clients given double-checks will get exponents above 28M. This should keep them out of the way of the leading edge and holding up progress on milestones.

3) Fast V5 clients requesting "do what makes the most sense" will be given double-checks 15% of the time, down from 25%.

4) If I can make it happen, 53M-60M will be available for an extra bit of TF. The theory is GPUs are bloody fast at TF which changes the break-even formulas for TF vs. LL.

[petrw1]

Cool.

Do you have any way of knowing if a client is running a GPU and then limit the extra bit to them?

[Prime95]

Originally Posted by petrw1

Do you have any way of knowing if a client is running a GPU and then limit the extra bit to them?

Nope.

[Brain]

Originally Posted by Prime95

Effective today:
4) If I can make it happen, 53M-60M will be available for an extra bit of TF. The theory is GPUs are bloody fast at TF which changes the break-even formulas for TF vs. LL.

Seems to be active and working...:
Factor=XYZ...,53138783,69,70

[davieddy]

Originally Posted by Prime95

Effective today:

4) If I can make it happen, 53M-60M will be available for an extra bit of TF. The theory is GPUs are bloody fast at TF which changes the break-even formulas for TF vs. LL.

I think this extra TF has been happening for a few weeks.
There has been (mass?) debate elsewhere as to how the "break-even"
point works out with different hardware.
IMHO if GPUs are shit hot at TF, then let them go for it.
After all, finding a factor is more of a proof of compositeness
than 2 LL tests.

David

[petrw1]

Originally Posted by davieddy

I think this extra TF has been happening for a few weeks.
There has been (mass?) debate elsewhere as to how the "break-even"
point works out with different hardware.
IMHO if GPUs are shit hot at TF, then let them go for it.
After all, finding a factor is more of a proof of compositeness
than 2 LL tests.

David

A couple months ago George released the last bit of TF that was supposed to happen AFTER the P-1. TF was getting so far ahead of LL, partly due to GPUs he decided to let this last bit of TF go first with P-1 to follow.

However, what George is referring to in this thread is releasing ANOTHER bit for TF in this range of exponents over and above the prescribed limits in The Math page. http://www.mersenne.org/various/math.php

[Christenson]

Originally Posted by Prime95

Nope.

Actually, I think that there's quite a bit of information as to whether a GPU or a CPU did it.

If it is automatically submitted, then a CPU did it with Prime95. Mfaktc doesn't yet know how to do this -- and if there's a way in the web interface, I'll be happy to include it when mfaktc learns how.

If it is manually submitted, then a GPU may have done it, and if Prime95 did it, someone is doing extra work for some reason. Certainly many GPU'ers have been doing a bit or three more than assigned. Also, when the server parses the manual lines from results.txt, GPU results contain "mfaktc" in them.

You can also go by GHz-days per day -- unless you are looking at my slow, cheap GPU, which only does as well as a CPU.

[Prime95]

Originally Posted by Christenson

Actually, I think that there's quite a bit of information as to whether a GPU or a CPU did it.

I think the original question referred to whether Primenet can tell if a reservation request is coming from a GPU or CPU.

I agree with you that the server could be beefed up to know if a result came from a GPU or CPU.

[Prime95]

More tweaks:

1) You can now extend manual assignments above 100M for more than a year.
2) Manual reservations of exponents above 100M will now expire in 1060 days (was 180).

[RMAC9.5]

I have 2 low end PCs (Pentium III and Athlon 600) which are TWICE as efficient doing "Trial factoring to low limits" as they are on anything else. Consequently, that is the work they do most of the time. However, the server ONLY allows them to download 14 new numbers to work on each time they dial up for more work. Can this number be increased to a more reasonable value as it represents only 1 or 2 days work for each PC?

Minor Server Bug report: I also have a version 24.13 PC running Windows Server 2003 (64 bit OS) which does ONLY trial factoring. The server assigns it 2^71 trial factoring work which is fine with me. When this PC reports that it did NOT find a factor, the server correctly assigns it trial factoring credit. When it does find a factor, the server incorrectly assigns it P-1 credit.

[markr]

Originally Posted by RMAC9.5

I have 2 low end PCs (Pentium III and Athlon 600) which are TWICE as efficient doing "Trial factoring to low limits" as they are on anything else. Consequently, that is the work they do most of the time. However, the server ONLY allows them to download 14 new numbers to work on each time they dial up for more work. Can this number be increased to a more reasonable value as it represents only 1 or 2 days work for each PC?

You can have the client keep a longer queue, if that would help:

Originally Posted by undoc.txt

The program will restrict how many exponents can be added to worktodo.txt.
To override this, change prime.txt:
MaxExponents=n

The default is 15.

Alternatively, you could grab a slab of manually-chosen work using Uncwilly's LMH guide.