TF-LHM Limit suggestion....
 

Can I suggest that the TF-LMH limit be increased to 64 bits since that seems to be a performance dividing line for older artitecture PCs. Going up to 64 would still be efficient for even the slowest PC (my PIII 866 could finish up to 64 in less than 1 hour).

I have two older PC's running TF-LMH (a PIII and an Athlon).
They both perform very good up to 64 bits. 65 bits takes 6 times longer than 64 (not twice as you might expect).

However I am getting assignments on both up to 63 bits in the current 140M ranges. Is everyone getting 63 bits? The PIII takes about 26 minutes for 58-63 bits; the Athlon about 17 minutes.

63 and 64 bits are actually handled best by Athlons running 64-bit OS and clients. But I agree that at 130M, 63 bits goes by too fast even for slow machines. Also, perhaps the 56-62 range should be unified to cut down the amount of server communication required.

[QUOTE=garo;164652]I agree that at 130M, 63 bits goes by too fast even for slow machines.[/quote]

Done. Assignments are now to 2^64 for exponents between 100M and 400M, 2^65 to 800M, and 2^66 to 1B.

[quote] Also, perhaps the 56-62 range should be unified to cut down the amount of server communication required.[/QUOTE]

Improved in 25.9 build 4.

[QUOTE=petrw1;163146]Today at 2009-02-17 14:16 Worker #1 Unreserved all 15 LL assignments (not the DC tests) and then proceeded to get new work.[/QUOTE]

To all sufferers of the unreserve bug:

By any chance was the client doing P-1 when this happened? P-1 sometimes reports percent complete over 100% - I haven't figured out that bug. A side effect, fixed in 25.9, is that estimated completion dates were not calculated properly leading to erroneous unreserves.

For me the assignment didn't start yet...but P-1 was done for that exponent already, it just needed the actual LL test.

The question relates to the exponents that were being tested at the time...not the exponents that were unreserved.

[QUOTE=Prime95;165030]To all sufferers of the unreserve bug:

By any chance was the client doing P-1 when this happened? P-1 sometimes reports percent complete over 100% - I haven't figured out that bug. A side effect, fixed in 25.9, is that estimated completion dates were not calculated properly leading to erroneous unreserves.[/QUOTE]

At the time this affected PC was on (and still is on) 25.9 Build 3.

I don't think it was doing P-1; I say that because this PC never has produced any P-1 results; unless it was doing P-1 and that was one of the assignments dropped at the time ... and before it competed the P-1.

There are a lot of important bugs fixed in 25.9 (GOOD!) however, admittedly it is a few percent slower for PIV machines - 4 of my 7 - (NOT GOOD!). This makes the decision to upgrade somewhat cloudy.

In my experience, I find that V24 actually seems to do a better job estimating completion dates. I had a machine offline for about a week recently; the PIV Equivalency dropped and all the estimated completion dates were pessimistic (about 15%). I have a Quad that due to some kind of typical contention when all 4 cores are running they all slow down a little (maybe also 20%); however the estimated completion times there are too optomistic in that they seem to be based on theoretical thruput. This all being said it does get better over time so maybe once these Equivalency Factors have time to level off the estimates will be better. Thanks.

[QUOTE=Prime95;165028]Done. Assignments are now to 2^64 for exponents between 100M and 400M, 2^65 to 800M, and 2^66 to 1B.
[/QUOTE]

Thanks

P.S. And welcome back...any trip hilights?

[QUOTE=petrw1;165038]...any trip hilights?[/QUOTE]

All of Australia was a highlight, probably our best vacation to date.

[QUOTE=petrw1;165037]At the time this affected PC was on 25.9 Build 3.

I don't think it was doing P-1; I say that because this PC never has produced any P-1 results; [/QUOTE]

Thanks, that's what I needed to know. I'll install some more safety measures.

Two more questions, were the unreserved exponents from one worker or both workers? In prime.log were the new exponents reserved seconds after unreserving or several minutes/hours later?

[QUOTE=Prime95;165042]Two more questions, were the unreserved exponents from one worker or both workers? In prime.log were the new exponents reserved seconds after unreserving or several minutes/hours later?[/QUOTE]

Worker 1 of a Duo ... I'll check the log tomorrow but I believe it was immediate.

[QUOTE=Prime95;165042]Two more questions, were the unreserved exponents from one worker or both workers? In prime.log were the new exponents reserved seconds after unreserving or several minutes/hours later?[/QUOTE]In my case: only one worker affected out of four on a quad, and seconds later. There was no p-1 running or lined up. The client is mprime 25.9 build 3, on Ubuntu 64-bit. I had just stopped the client, entered "./mprime -m", and it immediately unreserved & reserved.

At that stage I hadn't got around to disabling speedstep in bios, if that might be a factor.

[QUOTE=Prime95;165030]P-1 sometimes reports percent complete over 100% - I haven't figured out that bug.[/QUOTE]

A possibly related issue is that P-1 sometimes 'sticks' at 100%, so that if I set reporting to every 100 iterations, say, the percentage reported during sucessive outputs might be 99.2%, 99.5%, 99.8%, 100.0%, 100.0%, 100.0%,..., before eventually going to

I suspect that the percentage reported is actually a little higher than the amount actually done.

(Client version 25.7 build 3)

[QUOTE=petrw1;165043]Worker 1 of a Duo ... I'll check the log tomorrow but I believe it was immediate.[/QUOTE]

See log excerpt immediately following ... there is no time stamp between the Unreserving and Getting Assignment so can I assume it was immedidate, that is without a gap between?

This was not the regular "Send new completion dates" time and it did not complete an assignment at this time an need to communicate for another one. There might have been system restart at this time but we can't remember for sure ... could the trigger have been something on the server?

P.S. My time zone is 6 hours behind the server ... this would have happened 14:16:31 on your end.
[QUOTE]
[Tue Feb 17 08:16:31 2009 - ver 25.9]
Unreserving M28650653
URL: [url]http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=au&g=ddaa0b55c505cc507d0e9650f885192c&k=07718BE28C7914674B7B4F514E2B6F8A&ss=5214&sh=5AE761189DABBD68F695B3E9D9CD1A5B[/url]
RESPONSE:
pnErrorResult=0
pnErrorDetail=SUCCESS
==END==

------------ 13 more 'Unreserving' sections deleted --------------

Unreserving M28260691
URL: [url]http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=au&g=ddaa0b55c505cc507d0e9650f885192c&k=7353FCF8C1B021F5528DD87C1A87A9A2&ss=15987&sh=A0A017CF7D80A203E389D269E4DE7D8A[/url]
RESPONSE:
pnErrorResult=0
pnErrorDetail=SUCCESS
==END==

Getting assignment from server
URL: [url]http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=ga&g=ddaa0b55c505cc507d0e9650f885192c&c=0&ss=14878&sh=A819EE00D5A646299F4DD66A9C5C62C9[/url]
RESPONSE:
pnErrorResult=0
pnErrorDetail=Server assigned Lucas Lehmer primality test work.
g=ddaa0b55c505cc507d0e9650f885192c
k=8CCEA7271AA92BD8AC194D817A194FA4
A=1
b=2
n=28203107
c=-1
w=100
sf=68
p1=1
==END==

PrimeNet success code with additional info:
Server assigned Lucas Lehmer primality test work.
Got assignment 8CCEA7271AA92BD8AC194D817A194FA4: LL M28203107
Sending expected completion date for M28203107: Mar 25 2009
URL: [url]http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=ap&g=ddaa0b55c505cc507d0e9650f885192c&k=8CCEA7271AA92BD8AC194D817A194FA4&c=0&p=0.0000&d=86400&e=3108832&ss=11266&sh=86CB7086995B0BB2B78DAE36E5D39F56[/url]
RESPONSE:
pnErrorResult=0
pnErrorDetail=SUCCESS
==END==

-------------- 5 more 'Getting Assignment' sectons ----------
[/QUOTE]

[QUOTE=Mr. P-1;165072]A possibly related issue is that P-1 sometimes 'sticks' at 100%, so that if I set reporting to every 100 iterations, say, the percentage reported during sucessive outputs might be 99.2%, 99.5%, 99.8%, 100.0%, 100.0%, 100.0%,...[/QUOTE]

This is the "over 100%" bug. The output code works around the bug by displaying 100% for anything over 100%. The root cause of how the percent complete goes over 100 remains unsolved.

[QUOTE=petrw1;165074]This was not the regular "Send new completion dates" time and it did not complete an assignment at this time an need to communicate for another one. There might have been system restart at this time but we can't remember for sure ... could the trigger have been something on the server?[/QUOTE]

This is definitely not a server problem.

Is this system also afflicted with SpeedStep? That could possibly cause unreserves, but it should not immediately then do reserves. Those timestamps are not output if less than 5 minutes have passed. I suppose it is possible that the client unreserved because of a slow cpu speed, cpu speed changed, and new exponents were reserved all withing 5 minutes.


In summary, we have 2 or 3 causes of unreserves:

1) P-1 over 100% complete bug. "Fixed" in 25.9.

2) Speedstep. You can workaround this by setting CpuSpeed in local.txt or by making UnreserveDays really huge.

3) Some other undiagnosed cause.

[QUOTE=Prime95;165076]This is definitely not a server problem.

Is this system also afflicted with SpeedStep?

In summary, we have 2 or 3 causes of unreserves:

1) P-1 over 100% complete bug. "Fixed" in 25.9.

2) Speedstep. You can workaround this by setting CpuSpeed in local.txt or by making UnreserveDays really huge.

3) Some other undiagnosed cause.[/QUOTE]

I was not implying a server problem but rather that the server initiated the communication with my PC that resulted in the unreserve because my understanding is that the only times the PC talks to the server is:
- At the "send new end dates" time
- When an assignment is completed
- At reboot
- By me communicating manually or asking for work or unreserving work, etc.
I don't think any of these happened.

I have never heard of Speedstep so I don't know if I have it.

I had Unreserve days at about 250 and had about 220 days of work for this worker. It had 6 18M DC tests and then 15 28M LL tests. Only the 15 LL were Unreserved and then it got 6 of them back to get it up to 90 days.

Thanks.

[QUOTE=petrw1;165080]I have never heard of Speedstep so I don't know if I have it.

I had Unreserve days at about 250 and had about 220 days of work for this worker.[/QUOTE]

Speedstep is the Intel feature that clocks the CPU way down (like 700MHz) when the CPU is relatively idle. When mprime starts after a reboot, it measures the CPU speed as 700 rather than the usual 2400 or 2600 or 2800 that your computer usually runs at. Thus the estimated completion dates are about a factor of 4 off resulting in some unreserves.

P.S. The server cannot initiate communication with the client.

[QUOTE=Prime95;165085]Speedstep is the Intel feature that clocks the CPU way down (like 700MHz) when the CPU is relatively idle. [/QUOTE]

OK thanks, so how do I know if I have it?

Longer duration of TFLOPS graph....
 

The 7 day graph on this page is interesting....
[url]http://www.mersenne.org/primenet/[/url]

but I suggest graphing it over a much longer term (365 days?) would better indicate how the projects is growing (hopefully).

Someone keeps stealing my assignments!
 

Not for the first time I have received a string of "Result not needed" responses from the server when my laptop returns its work. I don't mind what exponents I test but it is pointless doing the same work as someone else, worse there could be a bug meaning that the wrong work is being reported as done. Today this problem affected about four complete TF-LMH assignments, it always seems to be the same other account that does the work before I do, called "monst". I have attached a screen shot of one such exponent status. Does anyone have any ideas why this is happening?

Miles

[QUOTE=g0ods;165487]Not for the first time I have received a string of "Result not needed" responses from the server when my laptop returns its work. I don't mind what exponents I test but it is pointless doing the same work as someone else, worse there could be a bug meaning that the wrong work is being reported as done. Today this problem affected about four complete TF-LMH assignments, it always seems to be the same other account that does the work before I do, called "monst". I have attached a screen shot of one such exponent status. Does anyone have any ideas why this is happening?

Miles[/QUOTE]

Not that it's much comfort, but count yourself lucky it's only four!
I just reported 807 LMH results for exponents in the 125M range that I
claimed about a week ago via the manual testing pages. 804 of
them already had results reported for the factoring range I'd worked on!
I got credit for only three :-(

Graff

[QUOTE=Graff;165520]Not that it's much comfort, but count yourself lucky it's only four!
I just reported 807 LMH results for exponents in the 125M range that I
claimed about a week ago via the manual testing pages. 804 of
them already had results reported for the factoring range I'd worked on!
I got credit for only three :-(

Graff[/QUOTE]

It does appear that someone(s) is "clearing up" incomplete LMH in the 100-130M range. Systematically over the last few weeks ranges that were less than the assigned 63 bits showed up on the distribution map with over 20,000exponents suddenly assigned. Now if that person simply grabbed all exponents under 63 bits in that range without checking for those already assigned to someone then your results and those of g0ods could have happened.

Similarly I have had some TF assignments from a sporadic v4 client (on a PC I no longer have access to) recently completed by someone else. These may have been deemed abandoned and released by the server, and as they complete my PC is likely being told "too late". Is it possible this is your scenario?

Correct me if I'm wrong - can't unreserve V4_Comp
 

I have a suspicion that the Assignments Details screen should NOT allow Unreserve for V4_Computers.

A couple months ago I did just that and unreserved about a dozen TF assignments from a v4_computer. About a month later they reappeared as assignments but this time as LL. Every couple days another one stops reporting and shows overdue with no result showing up. When I do an Exponent Status it shows the TF as complete by someone else with a date in the recent past but later than the date I unreserved them.

I don't have access to this PC anymore and it is powered up and used sporadically (a few times a month) so I am only guessing but I think what happened is:

1. I unreserved the TF assignments
2. The V5 Server declared them available and reassigned them but was NOT able to notify the V4 client to drop them.
3. The next time the V4 client communicated a few weeks later it said "I am still working on these assigments".
4. The server noticed the TF had already been completed and decided it must be doing LL instead.
5. The client completed the TF and reported in and went on to the next one.
6. The server said: "Result not needed" since someone else completed this already and did not report a result.

Does this make sense?

[QUOTE=petrw1;165523]It does appear that someone(s) is "clearing up" incomplete LMH in the 100-130M range. Systematically over the last few weeks ranges that were less than the assigned 63 bits showed up on the distribution map with over 20,000exponents suddenly assigned. Now if that person simply grabbed all exponents under 63 bits in that range without checking for those already assigned to someone then your results and those of g0ods could have happened.[/QUOTE]

Unlikely. I grabbed some large number of exponents (maybe 20000, about
two weeks worth of work, assuming lightly-loaded machines) a short
while back, mostly in the 125M-126M range. I reserved the exponents
using the manual reservation form using a curl script. I prepared two lists
for each 1M range: one of exponents factored to 2^63 or above; one of
exponents factored factor up to 2^62. I reduced the number of entries
in this latter list by combining exponents into ranges where no exponent
was at 2^63 or above. Each range was then requested from the manual
reservation script using the curl script. The output returned by the
script was parsed. A small number of the exponents were already
assigned and so were ignored. The remainder had been assigned to me
(i.e., I got a 32-hexdigit assignment key for each exponent) and were
added to my worktodo file.

I haven't figured out how to get the curl script to register the exponents
to my account, so they are shown as Anonymous. However, I get credit
when I report the results.

Graff

[QUOTE=petrw1;165652]A couple months ago I did just that and unreserved about a dozen TF assignments from a v4_computer. [B]About a month later they reappeared as assignments but this time as LL.[/B] Every couple days another one stops reporting and shows overdue with no result showing up. When I do an Exponent Status it shows the TF as complete by someone else with a date in the recent past but later than the date I unreserved them.

Does this make sense?[/QUOTE]I have expos that are TF assignments that show up as LL's. I have given up on trying to correct the server.

[QUOTE=Graff;165520]Not that it's much comfort, but count yourself lucky it's only four!
I just reported 807 LMH results for exponents in the 125M range that I
claimed about a week ago via the manual testing pages. 804 of
them already had results reported for the factoring range I'd worked on!
I got credit for only three :-(

Graff[/QUOTE]

My latest batch of 1721 results yielded only about 50 new results.
My 24-hour CPU meter, which normally lies between 100 and 250%,
is currently showing 8%.

Graff

Perhaps you should just let the server assign you stuff and if that is not possible - work on far out ranges - those that have not and are not in any danger of being assigned by the server.

Finally, it might be useful to check the status of your assigned exponents using this page:
[url]http://v5www.mersenne.org/report_exponent/[/url]

And check the "show exponents assigned to me" box.

[QUOTE=garo;165730]Perhaps you should just let the server assign you stuff and if that is not possible - work on far out ranges - those that have not and are not in any danger of being assigned by the server.[/QUOTE]

This is not Prime 95 or mprime, so automatic server assignment is not
an option. In any case, I don't think that it would be any more secure
against poaching than using the manual assignment form. After all, both
methods give you an assignment key...

[QUOTE]Finally, it might be useful to check the status of your assigned exponents using this page:
[url]http://v5www.mersenne.org/report_exponent/[/url]

And check the "show exponents assigned to me" box.[/QUOTE]

As noted in an earlier message, I have not yet figured out how to
pass my username to the assign manual exponent script, so the
assignments are to Anonymous. When you use the manual
assignment page, the script "knows" who you are. Perhaps it
is reading a cookie... If anyone knows how to pass the
username, can they post the info here?

Graff

Try appending this to the URL:

?user_login=xxxx&user_password=xxxxxxxx&B1=GO

[QUOTE=petrw1;161581][QUOTE=petrw1;158782]

[CODE]Today's Numbers - Feb 4, 2009
Teams 152
Users 9410
CPUs 60018
TFLOP/s 42.110
GHz-Days 21054.916 [/CODE]

[/QUOTE]

6 more weeks, 20,000 more CPUs. The increase in CPUs shows no sign of slowing. However, the total TFLOPS is still not increasing by much.

And I never did personnally see 80,000 CPUs in V4.

[CODE]Today's Numbers
Teams 181
Users 13199
CPUs 80162
TFLOP/s 41.446
GHz-Days 20722.979 [/CODE]

The v5 server does not seem to include the last day of contact and percentage of work done in the reports on the assignments of exponents. The 'exponent status' page would be ideal to have such a listing. Can it be added as a feature?

Dropping CPU ... any risks/losses?
 

I have retired (replaced) an old CPU.

If I drop it from the Computer Details report will I KEEP all my Results, User points, Team points, etc., etc?

Do I lose any stats?
Are there any risks?
Is there any reason I should NOT drop it?

Thanks

ECM 365 and Lifetime stats mismatch....
 

On my User Summary I am talking about the 365 days stats compared to the lifetime stats.

When I look at my ranking (Rank) and the number of (Of) clients in every other stat except ECM the numbers are VERY close and often the same in both reports.

However for ECM the numbers differ by quite a bit relatively:

163 of 264 vs. 170 of 272.

If it possible one reports considers ECM-Fermat as well but the other does not?

No; It simply means there are 8 people who didn't do ECM within the last 365 days but 7 of them still have a higher ECM-M GHz-days value than you currently have.

For me that's 4 people (I'm #23 and #27, respectively), and I can name them. I'll leave that as an exercise to you. :wink:

[QUOTE=ckdo;166426]No; It simply means there are 8 people who didn't do ECM within the last 365 days but 7 of them still have a higher ECM-M GHz-days value than you currently have.

For me that's 4 people (I'm #23 and #27, respectively), and I can name them. I'll leave that as an exercise to you. :wink:[/QUOTE]

If I understand correctly, the V5 clock started Oct 20, 2008 (after the v4 crash)....in that case, until Oct 20, 2009 the two reports should be identical...NO???

No.

[quote=Old man PrimeNet;108341]The v5 server is populating itself with 46.2 million alpha test LMH factoring assignments (p>79.3M) as I write this.[/quote]

That's probably when time began, as far as v5 is concerned.

[QUOTE=ckdo;166435]No.


That's probably when time began, as far as v5 is concerned.[/QUOTE]

Fair enough ... then shouldn't all stats categories have similar discrepancies between 365 and lifetime? Every other one is very close or identical.

[quote=petrw1;166436]Fair enough ... then shouldn't all stats categories have similar discrepancies between 365 and lifetime? Every other one is very close or identical.[/quote]

I think it just means that all categories other than ECM have seen so much work in the last 365 days that work done prior to March 24th 2008 does not have much impact on the rankings but not so with ECM. try to generate a customized report of ECM before March 24 2008 and compare with the current report. Then repeat the exercise for other categories.

YMMV significantly - right now, my 365 day & lifetime ranks for P-1, ECM & ECMF are different - even if by only one. It's likely no coincidence that these worktypes have the lowest GHz-days.

[QUOTE=Prime95;165028]Done. Assignments are now to 2^64 for exponents between 100M and 400M, 2^65 to 800M, and 2^66 to 1B.[/QUOTE]

Can I make one more suggestion...

As I am watching the LMH assignment giving in the 150-159M range it appears that any exponent that is already TF'd to at least 60 bits is bypassed ... case in point, after completion of my assignments in the 150M range my next assignment was 155M. The intervening assignments were all at 60 Bits.

Would it be reasonable to give out any LMH assignments that are below the limits in your quote above; even if only 1 bit level low (i.e. 63 bits)?

Thanks

[quote=petrw1;166653]Would it be reasonable to give out any LMH assignments that are below the limits in your quote above; even if only 1 bit level low (i.e. 63 bits)?[/quote]
While we are on the subject of Lone Mersenne Hunters, they might find it useful if [U][url]http://www.mersenne.org/report_factoring_effort/[/url][/U] had an option to exclude assigned exponents.

[quote]While we are on the subject of Lone Mersenne Hunters, they might find it useful if [U][url]http://www.mersenne.org/report_factoring_effort/[/url][/U] had an option to exclude assigned exponents.[/quote]

Ask and ye shall receive.

[QUOTE=Prime95;166686]Ask and ye shall receive.[/QUOTE]

:bow:
I should have asked sooner.....

Could we also have options to specify ranges for B1 and B2 as we do for 'how far factored', please?

[quote=Prime95;166686]Ask and ye shall receive.[/quote]


Thank you George!

One of my V4 PCs just returned a DC and I naturally went to check my statistics. All of GHz values for the Lifetime and Last 365 Days are exactly the same, but my overall rankings (89 - Last 365 Days; 90 - Lifetime) differ by one. Is this a "bug"?

I also noticed that the V5 server had cloned one of my V5 PCs even though I have not done any of the normal things (e.g. re-install Windows, etc.) that cause this problem. The only changes made to this PC are small changes to the CPU speed (about 50 MHz) and a memory increase from 2 GB to 4 GB.

Two requests:

First, can some one add a GIMPS Forum link to the PrimeNet 5.0 home page under the current GIMPS Home link? It would make "finding" this forum easier for new Prime95 enthusiasts.

Finally, can the server's V4 API be changed to "capture" the V4 PC name when results are returned since it is part of the text message from the V4 PC (e.g. UID: RMAC9.5/Dad_s_Other_,)? This would help those of us who have "borged" V4 PCs that we no longer have access to.

[QUOTE=RMAC9.5;166746]One of my V4 PCs just returned a DC and I naturally went to check my statistics. All of GHz values for the Lifetime and Last 365 Days are exactly the same, but my overall rankings (89 - Last 365 Days; 90 - Lifetime) differ by one. Is this a "bug"?
[/QUOTE]

See #326-332 above. I asked this same question a few days ago.

Petrw1,
Thank you for your kind reply but I don't think you understood my question.
I had previously read the posts that you referenced and I understood how individual LL, TF, ECM, etc. rankings could vary between Lifetime and Last 365 Days depending on each user's imported V4 credits. However, the [B]overall[/B] rankings for the [B]total amount of work[/B] done should be the [B]same[/B] if the total Lifetime and Last 365 Days GHz values are the [B]same[/B] (which they were). In any event, the rankings now match (89), the total GHZ values still match (16,154.2306), and life is good.

How does one get 0.0000 points???
 

At the bottom of every top-producers report are a handful of users with 0.0000 points. Except for the case of finding a very small factor (<60 bits) how does someone get 0.0000 points?

I am assuming you do NOT appear on the report until you have completed an assignment and submitted the result...is this where I err?

Is it from submitting results later deemed invalid?

Revelation: I think it just might be that they are on the report because they have results OLDER than 365 days but none in the last 365 days. By default the Top Producers reports are for the last 365 days.

[QUOTE=RMAC9.5;166839]However, the [B]overall[/B] rankings for the [B]total amount of work[/B] done should be the [B]same[/B] if the total Lifetime and Last 365 Days GHz values are the [B]same[/B] (which they were).[/QUOTE]Life's not so simple - your ranking depends on others' GHz values also. Once someone has been collecting v5 credits for more than a year, their 365 day running total can go up and down, depending on how credits in the last 24 hours compare to the 24 hours a year ago. (It stays less than their lifetime total, though, obviously.) So you might stand still in GHz but gain in ranking while someone else slips below you. The overall total works the same as its components.
[QUOTE=RMAC9.5;166839]I understood how individual LL, TF, ECM, etc. rankings could vary between Lifetime and Last 365 Days depending on each user's imported V4 credits.[/QUOTE]I think the only effect of the imported v4 credits will be when they drop out of the 365 day running total. (Or if someone still has some to link in, there'd be an effect then.)

[QUOTE=petrw1;166409]I have retired (replaced) an old CPU.

If I drop it from the Computer Details report will I KEEP all my Results, User points, Team points, etc., etc?

Do I lose any stats?
Are there any risks?
Is there any reason I should NOT drop it?

Thanks[/QUOTE]

:bump:

v4_computers question
 

When I review my Computer Details on PrimeNet 5.0, I see one v4_computers entry which shows my accumulated GHz-Hrs from PrimeNet 4.0, but it also is marked as "At least one cpu is 90 days or more unreported and appears lost." My Work Results Details show that two of the exponents that my "v4" computers started processing were completed by one of my "v5" computers:

[SIZE=2]CPU Name[/SIZE][SIZE=2]ExponentResultType[/SIZE][SIZE=2]Received[/SIZE][SIZE=2]age[/SIZE][SIZE=2]days[/SIZE][SIZE=2]Result[/SIZE][SIZE=2]GHzDays[/SIZE]
[SIZE=2]Theresa[/SIZE][SIZE=2]45358069[/SIZE][SIZE=2]C[/SIZE][SIZE=2]2009-03-04 21:01[/SIZE][SIZE=2]55.3[/SIZE][SIZE=2]C13B67A2B7DAC5__[/SIZE][SIZE=2]78.7466[/SIZE]
[SIZE=2]Theresa[/SIZE][SIZE=2]45358021[/SIZE][SIZE=2]C[/SIZE][SIZE=2]2009-03-04 21:01[/SIZE][SIZE=2]55.3[/SIZE][SIZE=2]B5A68E61CA25FF__[/SIZE][SIZE=2]78.7466[/SIZE]
[SIZE=2]Harvey[/SIZE][SIZE=2]45873209[/SIZE][SIZE=2]NF-PM1[/SIZE][SIZE=2]2009-02-07 17:35[/SIZE][SIZE=2]17.5[/SIZE][SIZE=2]B1=550000, B2=14025000[/SIZE][SIZE=2]3.2327[/SIZE]
[SIZE=2]Harvey[/SIZE][SIZE=2]40756141[/SIZE][SIZE=2]C[/SIZE][SIZE=2]2009-02-07 17:35[/SIZE][SIZE=2]89.3[/SIZE][SIZE=2]21F0B0348CA0C6__[/SIZE][SIZE=2]70.7572[/SIZE]
[SIZE=2]Theresa[/SIZE][SIZE=2]45358021[/SIZE][SIZE=2]NF-PM1[/SIZE][SIZE=2]2009-01-21 15:06[/SIZE][SIZE=2]13.0[/SIZE][SIZE=2]B1=540000, B2=13905000[/SIZE][SIZE=2]3.3973[/SIZE]
[SIZE=2]Theresa[/SIZE][SIZE=2]45358069[/SIZE][SIZE=2]NF-PM1[/SIZE][SIZE=2]2009-01-21 15:06[/SIZE][SIZE=2]13.0[/SIZE][SIZE=2]B1=540000, B2=13905000[/SIZE][SIZE=2]3.3973[/SIZE]
[SIZE=2]Theresa[/SIZE][SIZE=2][COLOR=red]47828503[/COLOR][/SIZE][SIZE=2]C[/SIZE][SIZE=2]2009-01-21 15:06[/SIZE][SIZE=2]54.7[/SIZE][SIZE=2]F1B64152ACC602__[/SIZE][SIZE=2]83.0356[/SIZE]
[SIZE=2]Theresa[/SIZE][SIZE=2][COLOR=red]47827553[/COLOR][/SIZE][SIZE=2]C[/SIZE][SIZE=2]2009-01-21 15:06[/SIZE][SIZE=2]54.7[/SIZE][SIZE=2]E78F90A72E1154__[/SIZE][SIZE=2]83.0339[/SIZE]
[SIZE=2]Harvey[/SIZE][SIZE=2]45358303[/SIZE][SIZE=2]NF-PM1[/SIZE][SIZE=2]2009-01-21 04:44[/SIZE][SIZE=2]12.6[/SIZE][SIZE=2]B1=540000, B2=13905000[/SIZE][SIZE=2]3.3973[/SIZE]
[SIZE=2]Harvey[/SIZE][SIZE=2]42074939[/SIZE][SIZE=2]C[/SIZE][SIZE=2]2009-01-12 03:02[/SIZE][SIZE=2]45.2[/SIZE][SIZE=2]5657430D14FE4E__[/SIZE][SIZE=2]73.0468[/SIZE]
[SIZE=2]v4_computers[/SIZE][SIZE=2][COLOR=red]47828503[/COLOR][/SIZE][SIZE=2]NF-PM1[/SIZE][SIZE=2]2008-12-27 14:55[/SIZE][SIZE=2]29.6[/SIZE][SIZE=2]B1=555000, B2=13181250[/SIZE][SIZE=2]3.3664[/SIZE]
[SIZE=2]v4_computers[/SIZE][SIZE=2][COLOR=red]47827553[/COLOR][/SIZE][SIZE=2]NF-PM1[/SIZE][SIZE=2]2008-12-27 14:54[/SIZE][SIZE=2]29.6[/SIZE][SIZE=2]B1=555000, B2=13181250[/SIZE][SIZE=2]3.3664[/SIZE]
[SIZE=2]v4_computers[/SIZE][SIZE=2]44039441[/SIZE][SIZE=2]C[/SIZE][SIZE=2]2008-11-27 23:54[/SIZE][SIZE=2]0.0[/SIZE][SIZE=2]C3BC6EF695AEC8__[/SIZE][SIZE=2]76.4574[/SIZE]
[SIZE=2]v4_computers[/SIZE][SIZE=2]44212237[/SIZE][SIZE=2]C[/SIZE][SIZE=2]2008-11-27 23:53[/SIZE][SIZE=2]0.0[/SIZE][SIZE=2]012769E43486EF__[/SIZE][SIZE=2]76.7574[/SIZE]
[SIZE=2]v4_computers[/SIZE][SIZE=2]44212237[/SIZE][SIZE=2]NF-PM1[/SIZE][SIZE=2]2008-11-27 23:53[/SIZE][SIZE=2]0.0[/SIZE][SIZE=2]B1=530000, B2=13382500[/SIZE][SIZE=2]3.3044[/SIZE]

Is there something else I need to do to complete my v4 migration? Or should I just not worry about that "90 days unreported" flag on my v4_computers entry? Thanks for your help.

I perform double checking. I had a result that did not match the first LL test so I was not credited. How do I find which number this was without having to search everyone of my results one by one? Thanks....

[URL="http://v5www.mersenne.org/report_LL/?exp_lo=1&exp_hi=100000000&exp_date=&user_only=1&user_id=xxxx&exfactor=1&dispdate=1&B1=Get+LL+data"]Lucas-Lehmer test results - PrimeNet[/URL]

Replace xxxx with your username and click this link after having logged into Primenet.

[quote=almostfrugal;170427]
Is there something else I need to do to complete my v4 migration? Or should I just not worry about that "90 days unreported" flag on my v4_computers entry? Thanks for your help.[/quote]

Don't bother about it. I have the same flag. You seem to be fully migrated.

100,000 CPUs!!!!!!!!!!!
 

[QUOTE=petrw1;166003][QUOTE=petrw1;161581]

6 more weeks, 20,000 more CPUs. The increase in CPUs shows no sign of slowing. However, the total TFLOPS is still not increasing by much.

And I never did personnally see 80,000 CPUs in V4.

[CODE]Today's Numbers
Teams 181
Users 13199
CPUs 80162
TFLOP/s 41.446
GHz-Days 20722.979 [/CODE][/QUOTE]

At the risk of sounding like a broken record....
Another 6 weeks (no sign of slowing), 20,000 more CPUs.
And even still TFLOP/s growing slower than the CPU ratio.
5,000 more Users

[CODE]Today's Numbers
Teams 204
Users 18186
CPUs 100187
TFLOP/s 43.836
GHz-Days 21917.990 [/CODE]


Where are all the CPUs coming from (other than my son's pat answer: "From a CPU factory.") ? Is this the wave we expected after two quick MP discoveries?

Perhaps some NPR listeners in the mix too?

2 curiosities about ECM
 

I've just completed a couple hundred ECM and a couple dozen ECM-F. Every assignment except a recent one was for 3 curves. This last one for F24 was only 1 curve. Why 1?

My bigger curiosity: With V5 the decision was made on TF assignments to send intermediate results to the server after every bit level (after 63 or so). This, I understand was to reduce the risk of losing work: In v4, if I was assignmed TF 63-69 and released the assignment or quit after 68 bits all the work would be lost (wasted).

Why is not the same thing done with ECM for the same reason? If I am assigned 3 (or 10) curves would it make sense to send results after each curve to not lose the work?

ECM-F seems frugal on points.
 

My 3.4 Ghz PIV can complete a P-1 on 50M in just under 2.5 days for about 4.3 points. : about 1.75 PPD.

ECM-F (F24) just over 3 days for just over 3 points with 768M RAM: 1 PPD.

LL/DC is almost 2 PPD.

I think that is to not encourage ECM too much. It doesn't really contribute to the main aim of GIMPS - to find Mersenne primes.

Some V4 TF Successes Reported as P-1 Results
 

Yesterday, one of my V4 PCs which does [B]only[/B] TF work reported 3 completed tasks to the V5 server through the V4 interface. Here are the Work Results Details:
v4_computers 70081909 F-PM1 2009-07-03 07:27 61.4 879094071157651347121 5.1624
v4_computers 70049131 NF 2009-07-03 07:26 23.2 no factor to 2^70 3.3604
v4_computers 70130579 NF 2009-07-03 07:26 30.2 no factor to 2^70 3.3565

Note, two of these results were given TF credit and one was given P-1 credit by the V5 server. Is the P-1 credit intentional or is this a bug?

[QUOTE=RMAC9.5;179710]Yesterday, one of my V4 PCs which does [B]only[/B] TF work reported 3 completed tasks to the V5 server through the V4 interface. Here are the Work Results Details:
v4_computers 70081909 F-PM1 2009-07-03 07:27 61.4 879094071157651347121 5.1624
v4_computers 70049131 NF 2009-07-03 07:26 23.2 no factor to 2^70 3.3604
v4_computers 70130579 NF 2009-07-03 07:26 30.2 no factor to 2^70 3.3565

Note, two of these results were given TF credit and one was given P-1 credit by the V5 server. Is the P-1 credit intentional or is this a bug?[/QUOTE]

IIRC, the client does nothing to indicate to the server what method was used to find a factor, so the server guesses based on the size of the exponent and factor.

[QUOTE=RMAC9.5;179710]Note, two of these results were given TF credit and one was given P-1 credit by the V5 server. Is the P-1 credit intentional or is this a bug?[/QUOTE]

I had this happen last fall too ... TF reported as P-1

I had factors credited as having been found by ECM even though I'd never performed ECM.

[QUOTE=RMAC9.5;179710]Yesterday, one of my V4 PCs which does [B]only[/B] TF work reported 3 completed tasks to the V5 server through the V4 interface. Here are the Work Results Details:
v4_computers 70081909 F-PM1 2009-07-03 07:27 61.4 879094071157651347121 5.1624
v4_computers 70049131 NF 2009-07-03 07:26 23.2 no factor to 2^70 3.3604
v4_computers 70130579 NF 2009-07-03 07:26 30.2 no factor to 2^70 3.3565

Note, two of these results were given TF credit and one was given P-1 credit by the V5 server. Is the P-1 credit intentional or is this a bug?[/QUOTE]

I'd say it means it is time to upgrade to v25.

[QUOTE=petrw1;179567]My 3.4 Ghz PIV can complete a P-1 on 50M in just under 2.5 days for about 4.3 points. : about 1.75 PPD.

ECM-F (F24) just over 3 days for just over 3 points with 768M RAM: 1 PPD.

LL/DC is almost 2 PPD.[/QUOTE]

The Pentium 4 seems to have particularly good match for LL tests. A combination of the fine tuning of the FFTs software in p95 and the speed ratio between float and integer instructions make the P4 more than almost any other cpu faster for LLs. (Obviously not in an absolute sense but in the relative sense of speed of various work units types)

I'm not entirely certain about the ECM code but it indicates to me that ECM is not quite as heavily dependent on float speed as the LL tests. ECM probably has some extra integer or address computation that shows up on the P4 speeds.

The reverse is true for certain models of AMD (especially in 64 bit mode) where the float/integer speed ratio leans much more to the integers resulting in much better PPD for TFs on those machines.

Two questions on 365 days Top Producers Report...
 

1. How does one be on these reports and yet have 0.000 points?

2. When you compute percentiles are these 0 point people included? The way I interpret percentiles is, if there are 1000 people on the list then each 10 people is 1 percentile. The top 10 are in the 100th percentile, the last 10 are in the 1st percentile. End even if someone in this bottom 10 with 0 points is declared in the 1st percentile then they should be counted in the total number for computing percentiles. So for example the LL list has 2745 names on it yet the user summary report shows my ranking as out of 2704.

[QUOTE=petrw1;181152]1. How does one be on these reports and yet have 0.000 points?

2. When you compute percentiles are these 0 point people included? The way I interpret percentiles is, if there are 1000 people on the list then each 10 people is 1 percentile. The top 10 are in the 100th percentile, the last 10 are in the 1st percentile. End even if someone in this bottom 10 with 0 points is declared in the 1st percentile then they should be counted in the total number for computing percentiles. So for example the LL list has 2745 names on it yet the user summary report shows my ranking as out of 2704.[/QUOTE]

I think there are some results that get 0.0001 to 0.0004 ghz-days that round of to zero with 3 digit fractions.

yes I expect they are counted.

[QUOTE=lfm;181209]I think there are some results that get 0.0001 to 0.0004 ghz-days that round of to zero with 3 digit fractions.
[/QUOTE]

That is a good possibility in the TF list but there are no LL tests in the last 365 days near the 0.0004 ghz-days range. That would have to be an exponent under 151,000. Way back in 1997 when this formal project started they were nearing 1,000,000.

Computer count way up ... thruput not so much so??
 

[CODE]Dec 24, 2008
Today's Numbers
Teams 121
Users 5791
CPUs 40240
TFLOP/s 38.349
GHz-Days 19174.259[/CODE]

[CODE]Today (July 20, 2009) almost half a year later:
Today's Numbers
Teams 237
Users 24121
CPUs 132926
TFLOP/s 44.165
GHz-Days 22082.610 [/CODE]

So over 6 months the CPU count has gone up 230%
Users count up 317%
while the TFLOPS/s rate has ONLY increased 15%.

Can anyone offer an explanation why these extra 92,000 CPUs appear to be adding very little to the thruput???

I'm not sure these can all be V4_Computers since I never saw a count much above 75,000 Computers in V4.

I guess the vast majority of these additions are people who doenload Prime95 and join GIMPS only to abandon their test thus not contributing to the throughput at all.

What about the self-cloning issue in Primenet where one CPU will spontaneously spawn itself into multiple IDs? (which can, of course, be manually merged, but most users won't notice this has happened, or bother to merge them).

But yes, a large chunk of users are always going to be the one-timers who GIMPS for a few hours or days then disappear.

Or. There have been an influx of new users after the latest find, and they just haven't returned anything yet?

[QUOTE=axn;182012]Or. There have been an influx of new users after the latest find, and they just haven't returned anything yet?[/QUOTE]

That would be plausible except for the fact that the number has been increasing quite consistently since December when it was at 40,000.

The expected drop when most v4 conversion were done did NOT happen, but then shortly after that there were THREE prime finds that may have bolstered interest....I still think it is odd that the thruput went up so little....this makes me tend towards James' suggestion.

So if I perform double checking and my residue doesn't match the prior result, this doesn't count as a success in the Top LL Double-Check Producers report. However, if at a later time, someone else verifies my result, do I get credit as a first-time LL on the Producers report? Or don't I get credit at all? This has happened to me three times with PrimeNet 5.0 (for example: 19341397).

[QUOTE=richs;186635]So if I perform double checking and my residue doesn't match the prior result, this doesn't count as a success in the Top LL Double-Check Producers report. However, if at a later time, someone else verifies my result, do I get credit as a first-time LL on the Producers report? Or don't I get credit at all? This has happened to me three times with PrimeNet 5.0 (for example: 19341397).[/QUOTE]
You lose the credit for an LL test if your result is later proved bad or a factor is found.

Apart from that, credit stays in the category (first-time test or double-check) the server gave the work to you as. :coffee:

[QUOTE=markr;186645]You lose the credit for an LL test if your result is later proved bad or a factor is found.[/QUOTE]I am almost certain this is not the case. At the moment when you get credit, you keep it, unless there is a manual intervention by the database administrators.

It used to be like that with PrimeNet v4 : Goerge maintained a top producer list that was different from the list automatically computed by PrimeNet.

Jacob

[quote=markr;186645]Apart from that, credit stays in the category (first-time test or double-check) the server gave the work to you as. :coffee:[/quote]

Actually, when doing double checks, you can have them credited as first time tests by editing your worktodo file... :wink:

[QUOTE=S485122;186649]I am almost certain this is not the case. At the moment when you get credit, you keep it, unless there is a manual intervention by the database administrators.

It used to be like that with PrimeNet v4 : Goerge maintained a top producer list that was different from the list automatically computed by PrimeNet.

Jacob[/QUOTE]
I may indeed have made the wrong assumption. You're right about the old setup, of course: one lost GIMPS credit but not v4 PrimeNet credit. I guess it would be more likely that the new PrimeNet would be more like the old PrimeNet than like the old GIMPS.

[QUOTE=S485122;186649]I am almost certain this is not the case. At the moment when you get credit, you keep it, unless there is a manual intervention by the database administrators.

It used to be like that with PrimeNet v4 : Goerge maintained a top producer list that was different from the list automatically computed by PrimeNet.

Jacob[/QUOTE]

Even in V4 (about 2005) I had 1 CPU that turned in several BAD LL results (I just didn't realize it until recently with the new LL by user report) but I never lost any credit for those results ... at least not in the PrimeNet list which I checked regularly. I checked the George list less frequently so I couldn't say whether I lost credit there or not.

The only reason that I asked the question is that on the Double-Checking Producers Report, it still shows that I have had 63 Successes in 66 Attempts, even though it really is 66 Successes.

I think some folks may be answering the wrong question.

It's not a question of richs's residue being incorrect. It's not a matter of richs's reporting a bad result.

What richs is asking about is a situation where:

A first-time LL residue, [U]with an incorrect value[/U], has previously been reported by someone else. Although this residue is incorrect, no one can know that until later.

When richs reports the ([U]correct[/U], as will be shown later) DC residue, PrimeNet does not credit richs with a success on the Top LL Double-Check Producers report because this DC residue doesn't match the first-time LL residue.

When will richs eventually get credit for that DC on some Top Producers report and on which report, once a triple-check shows that richs's residue was the one that was correct?

[QUOTE=cheesehead;186802]When will richs eventually get credit for that DC on some Top Producers report and on which report, once a triple-check shows that richs's residue was the one that was correct?[/QUOTE]Never : the success counter is only modified at the time a result is turned in. So in the case you return a residue that differs from a previously returned one, you do not increase your success counter. Once a triple check confirms one of both results, the triple checker sees her success counter increase, but the person that had returned that same confirmed residue does not.

Jacob

[QUOTE=S485122;186821]Never : the success counter is only modified at the time a result is turned in. So in the case you return a residue that differs from a previously returned one, you do not increase your success counter. Once a triple check confirms one of both results, the triple checker sees her success counter increase, but the person that had returned that same confirmed residue does not.[/QUOTE]So:

1[sup]st[/sup] time checks are actively encouraged no matter how crappy your hardware is (or if you feel inclined to fake a result).

2[sup]nd[/sup] checks are discouraged if you have good hardware due to your hard work being completely ignored if you are unlucky enough to get an exponent that has been tainted earlier by a previous tester.

3[sup]rd[/sup] checks are slightly better than 2[sup]nd[/sup] but you still need at least one honest tester with good hardware as one of the two previous testers.

[quote=retina;186836]
2[sup]nd[/sup] checks are discouraged if you have good hardware due to your hard work being completely ignored if you are unlucky enough to get an exponent that has been tainted earlier by a previous tester.
[/quote]

Not true. The success counter is not updated but you get credit for turning that result in. So your hard work is not ignored.