Replacing Entropia's primenet server

[trif]

Not giving credit for poaching would deter some poachers, but definitely not others. But the server should always give credit if you have legitimately been assigned an exponent anytime in the past year. So for the database folks, the server should keep track of the assignment history of an exponent. Probably the thing that would stop almost all poaching is if they got an email from George saying, "Please don't poach." :D It could even be automated, you return an exponent you were never assigned, and the server fires off an email. There also needs to be in place a mechanism for handling trailing edge assignments that will not complete in a reasonable amount of time, such as contacting the person assigned the exponent. I think that most of these poachers think that if they don't poach then an exponent with a projected completion of 300 days out will just sit there holding up a milestone.

Other things that could be done is to make poaching useless or at least appear to. If someone turns in a result for an exponent not assigned to them, it doesn't show up in the Completed Exponents report, and it disappears from the AER only if the computer that holds it checks in and reports that no work has been done on it (it is removed from the worktodo, no work has been wasted). If it subsequently expires, of course, it is removed and not handed back out. George could write a strong license for the use of Prime95 and the PrimeNet server (including the report pages).

Coupled with measures designed to prevent exponents from holding things up, poaching could be eliminated. But one thing that I have noticed is that diligent measures to work off exponents on the trailing edge just exposes exponents farther up to poaching. If the trailing edge of doublechecks right now was 7.5M, there would still be poachers with fast P4's who would decide on their own that six months was too long to complete a doublecheck.

One problem right now is machines that aren't on very often, but whoever installed Prime95 didn't change the "this machine runs 24 hours a day" setting. Prime95 is fairly good at adjusting the completion estimate when a machine is slower than usual due to CPU load and speed, but it doesn't adjust completion estimates at all if Prime95 isn't being run, or the computer is completely off. This leads to situations with machines reporting microprogress for a year or more, and having an estimated completion date of a few days forever. This is not so bad, but when these machines get down to less than the default 10 days expected completion, they go out and reserve another exponent, and that exponent will be out for the months/years it takes to complete the first assignment, and the time taken to complete the second assignment. The responsibility for adjusting requested assignments based on "do the work the makes the most sense" and time expected to completion is given to the client. I'd like to suggest that the new server code take that responsibility. That would also solve the problem of old clients still using the old breakpoints for LL/DC/TF and requesting work that will take a very long time to complete.

Poaching definitely hurts GIMPS. And something definitely needs to be done about it.

[Maybeso]

Originally Posted by trif

So for the database folks, the server should keep track of the assignment history of an exponent.

I agree, it should be kept with the logs. (or can it be mined from the logs?) The one danger would be database bloating -- you'd want to clear the info once the exponent had been completely processed.

Originally Posted by trif

... but it doesn't adjust completion estimates at all if Prime95 isn't being run, or the computer is completely off.

When prime95 starts up, it should compare the clock to the last timestamp of the most frequently updated file. It could add this 'dead' time to a total that gets reduced/eliminated whenever the server is contacted. Prime95 could use this total to adjust its estimates.

[outlnder]

Let them poach, but don't give them credit. Give the credit to whoever the exponent was assigned to.

This will either stop the poaching, since the poacher does not get credit, and it will give the person the exponent was assigned to the credit, thus negating any negativity that person may feel.

[Ian_H]

Originally Posted by Maybeso

When prime95 starts up, it should compare the clock to the last timestamp of the most frequently updated file. It could add this 'dead' time to a total that gets reduced/eliminated whenever the server is contacted. Prime95 could use this total to adjust its estimates.

I can see the attraction, but think it would still be necessary to allow more advanced users (for want of a better name) to enter data about hours per day etc. Past performance is not always an accurate guide to future performance.

I know when a computer is likely to be down for a day or two, and can adjust the hours per day to give an accurate estimate of the average uptime. The computer doesn't and can't. Similarly, I know when "real life" work demands are likely to significantly reduce the CPU cycles available to Prime95 - the computer doesn't.

On a separate subject, but still in this this thread, I disliked ebx's idea on allocating priority or 'juicy' assignments:

Originally Posted by ebx

Some example criteria for calculation could be
- at least 10 P90 years reported in the past 90 days

This would knock out a lot of users with just one or two fast boxes. Whether or not I can deal efficiently and quickly with an assignment does not depend on my total output in the last 90 days or any other period. It depends on the particular machine I run the assignment on and on my character/attitude.

[Prime95]

Originally Posted by Ian_H

I can see the attraction, but think it would still be necessary to allow more advanced users (for want of a better name) to enter data about hours per day etc. Past performance is not always an accurate guide to future performance.

Prime95 does what maybeso suggests. The more your machine is off, the more your RollingAverage in local.ini decreases.

Prime95 already does what Ian suggests too! Whenever you change the Hours-per-day value the RollingAverage is reset to 1000.

[Prime95]

Originally Posted by Ian_H

On a separate subject, but still in this this thread, I disliked ebx's idea on allocating priority or 'juicy' assignments:

I agree. A priority assignment should go to any computer that will complete it in a reasonable time period (say 3 months) and said
computer has already turned in a result. We want to give everyone with a decent computer and a proven track record an equal shot at these assignments.

I also think a new server should expire exponent all throughout the day - making it more difficult for folks to log in at a specific time to get expiring exponents. Note that I don't think there is anything unethical about the users currently doing this. The Primenet server rules are well known and these users are using intelligence and persistence to get exponents they prefer. All users have this opportunity.

[ebx]

[quote="Ian_H"]

Originally Posted by Maybeso

On a separate subject, but still in this this thread, I disliked ebx's idea on allocating priority or 'juicy' assignments:

This would knock out a lot of users with just one or two fast boxes. Whether or not I can deal efficiently and quickly with an assignment does not depend on my total output in the last 90 days or any other period. It depends on the particular machine I run the assignment on and on my character/attitude.

Just to make the point clear.

As I said, those were example numbers. If 5 years or 2 years is better, go for it. The numbers are for the box not the user account, by the way. True one can move assignments around but thats beyond control.

Whats so good about running a priority assignment on my box? Why would I want it if I know my machine is slow?

The key is to assign those numbers to creditible boxes without human interference. Reporting consistantly, predictiably is the way to build credit. Meanwhile, those more capable machines should be given more work.

[Ian_H]

Originally Posted by ebx

As I said, those were example numbers. If 5 years or 2 years is better, go for it. The numbers are for the box not the user account, by the way.

I know I can look this up, and I will, but what kind of box delivers 10 P90 years in 90 days? Not my P4 1.7 running 24/7, and I'd say that, at the moment, that's a machine that's good enough to be allowed to take a priority assignment.

You say that the figure could be 5 years or 2 years. I understand where you're coming from. But I still say that reliability may be best assessed by other measures. For example: how long has a user been around? How many numbers has she/he tested and returned. Priority assignments may need to be allocated to decent boxes, but they also need to go places we know they'll return from.

[ebx]

A lot of machines can do 40 P90 years per year, or 10 per 90 days. P4 1.7A should be real close if not already.

All measures we think good could be incorporated. But recent history carries more weight if I am to implement the rules.

[Deamiter]

[quote="Ian_H"]

Originally Posted by ebx

You say that the figure could be 5 years or 2 years. I understand where you're coming from. But I still say that reliability may be best assessed by other measures. For example: how long has a user been around? How many numbers has she/he tested and returned. Priority assignments may need to be allocated to decent boxes, but they also need to go places we know they'll return from.

As George has said, they'd have to have completed an exponent in the past 'n' months or whatever, but seriously, with a fast machine, and at the lower milestones (we're routinely testing numbers MUCH higher than 7M) speed should be a higher priority than reliability, as any (Athlon) box over 1.7 GHz will complete the current doublechecks in under 3 days... unless I'm missing something... With stats like that, the few power crunchers that do DC will eat through any milestone with ease!

[Ian_H]

Originally Posted by ebx

A lot of machines can do 40 P90 years per year, or 10 per 90 days. P4 1.7A should be real close if not already.

There must be something wrong with my arithmetic or my PCs - I'm getting nowhere near that.

Originally Posted by ebx

All measures we think good could be incorporated. But recent history carries more weight if I am to implement the rules.

An overdependence on one aspect of history, measured mechanically, would slow things down by excluding good participants with good machines. Suppose you get a new Pentium V 4.5GHz box next year: should you be expected to run it for 90 days before 'qualifying' for choice assignments? I'd rather trust you, based on a broader view of your reliability.