Updated Server Stats Page

[Old man PrimeNet]

After a week of chasing down archived and misplaced server transaction logs, cleaning up and reorganizing them, I finally got around to updating the stats chart:

http://mersenne.org/ips/stats.html

What's interesting is the hockey stick bend upward starting late 2001. I have (tentatively) attributed this to new CPUs & George's corresponding Prime95 code improvements leveraging them. Any speculation or high-confidence info on what brought this new, steeper performance growth trend?

[GP2]

This effect also shows up in the plots of P90 CPU years /day (7-day-average) from old copies of summary.txt (aka status.shtml, aka the output of http://www.mersenne.org/primenet/ ):

http://opteron.mersenneforum.org/png/LLspeed.png


It might perhaps be attributed to the arrival in force of Pentium 4s:

http://opteron.mersenneforum.org/png/machines.png


More graphs linked to at:
http://opteron.mersenneforum.org/


PS,
There is some preliminary evidence from http://opteron.mersenneforum.org/png/LLspeed.png that we may now have entered a "second bend" of the hockey stick with an even higher slope.

[GP2]

See also the Gigaflops rate greatly exceeds trend predicted 2 1/2 years ago thread from the Data forum, where some speculative theories were discussed.

[Prime Monster]

I am not sure about this, but I would think the arrival of the DC fanatic on the scene has had something to do with this. Instead of running the client as a background application on a machine otherwise used for other purposes, the client becomes the main and only application. The machines are tailored to run GIMPS and nothing else. The fanatics also run their machines 24/7/365, in difference to the casual user.

PM

[Joe O]

Originally posted by Old man PrimeNet
After a week of chasing down archived and misplaced server transaction logs, cleaning up and reorganizing them, I finally got around to updating the stats chart:

http://mersenne.org/ips/stats.html

Looks very nice! Thank you!

ps
Did you find any old summary.txt (aka status.shtml, aka the output of http://www.mersenne.org/primenet/ ) for GP2?

[tha]

Originally posted by Old man PrimeNet
After a week of chasing down archived and misplaced server transaction logs, cleaning up and reorganizing them, I finally got around to updating the stats chart:

Real nice to see the new graph, thank you!

Now that you have taken a turn at it, could you derive a graph from the data with all clients that log in, obtain assignments, but never have turned in any results eliminated? Or can you make the raw server data available to some selected users? (ehh, how many Mb's is it?) There are a few dataminers here that would enjoy delphing in it, don't you think GP?

I would like to check my conclusion that there have never been more than 16,000 clients active at any time.

YotN,

Henk.

[Old man PrimeNet]

How would we define 'active at any time' if a computer may not contact the server for up to several months, but may in fact be running the entire period?

[tha]

Originally posted by Old man PrimeNet
How would we define 'active at any time' if a computer may not contact the server for up to several months, but may in fact be running the entire period?

I made a graph myself based on the available data defining a client active from the first moment it turned in a result up to the last day it checked in a result. That is not excactly what I want, but close enough to be an indication.

With the server data available one would prefer this definition:

A client is assumed to have been active from the day it got an assignment up to the day it turns in that assignment. Overlapping assignments just counting as one contingeous period.

See my graphs at
http://home.planet.nl/~tha/primenetnumbers1.gif and
http://home.planet.nl/~tha/primenetnumbers2.gif

The low count is based on the file cleared.txt and the high count adds the data of status.txt to the first count.

YotN,

Henk Stokhorst

[Old man PrimeNet]

Using Henk's criteria, I get 44000+ 'live' CPUs queried directly from the server's SQL exponents assignment table. Exponents have about a dozen well-defined test states tracked as bit flags in an exponent state bit field, for example:

0x0200 exponent is assigned to a CPU
0x0400 factored composite
0x0800 LL composite
0x1000 prime
0x8000 marked for purge

PrimeNet's exponent state transition logic enforces consistency of the exponent states. Additional protections are applied through periodic, autonomous self-maintenance procedures - including the reclaimation of expired assignments.

So the SQL query, where a guaranteed-unique concatenation of the (case-sensitive in v4) userid and CPU names are counted distinctly across the exponents table where they are assigned and not completed for any reason, looks something like this:

select count(distinct(user_id + '^-/////-^' + machine_id))
from t_exponents_assigned
where state & 0x0200 = 0x0200
and state & 0x9C00 = 0

The summary.txt report shows the same number, which is even more conservative than Henk's criteria because after 60 days the server reclaims un-updated assignments as presumed lost. Sometimes this policy causes an unintentional (but routinely handled and credited) double-check condition when the 'lost' assignment suddenly checks in completed.

I'm not sure I understand how Henk arrives at his figures.

[pakaran]

Originally posted by Old man PrimeNet
How would we define 'active at any time' if a computer may not contact the server for up to several months, but may in fact be running the entire period?

Machine has exponents out. In the case of 10M numbers, which are not unreserved, the machine should have contacted the server in the past 90 days.

[GP2]

Originally posted by Old man PrimeNet
Exponents have about a dozen well-defined test states tracked as bit flags in an exponent state bit field, for example:

0x0200 exponent is assigned to a CPU
0x0400 factored composite
0x0800 LL composite
0x1000 prime
0x8000 marked for purge

Is it possible to do a synchronization "lite" on a more regular basis?

In a few cases, people report results directly to George so the server doesn't know about already-factored or already-verified-LL-composite exponents and reassigns them (for instance 17363977 and 20092067 and 20099983).