PIII TF Anomaly
 

I was reviewing TF performance for 3 of my PCs that were/are factoring.

I concentrated on the 58M-59M range as that is the one range all 3 have results in.

As expected each extra bit level about doubles the elapsed time ...

... with one exception:

From 64 to 65 bits my PIII time is almost quadruple 63 to 64 bits.
[CODE]
Bits P4 (Hrs) PIII (Hrs)
64 0.35 1.37
65 0.63 6.34[/CODE]

Is this simply a result of 32 vs 64 bit architecture?

[QUOTE=petrw1;152112]Summary (Last 365 days):

So I am overcounted by 1,708 TF[/QUOTE]

Individual TF-LMH result lines are deleted before 365 days pass. This explains the discrepancy. I've added a footnote to the results report.

[QUOTE=Prime95;152124]Individual TF-LMH result lines are deleted before 365 days pass. This explains the discrepancy. I've added a footnote to the results report.[/QUOTE]

This does NOT appear to be the case for my account.
My last TF completed Nov 9 10:13
My first TF-LMH completed Nov 9 10:15.

There is only a small (recent) gap in my Results between Nov 9 10:15 and Nov 10 00:23 accounting for about 400 results (I extract them regularly) .
The 1708 missing results would have taken my TF-LMH PIII-866 about 2.5 days.

Also, contrary to your new footnote the 400 or so missing results are still counted in the line: [U]petrw1 has 8,717 results in the last 365 days [/U]as that count matches the count in my extract file that includes the deleted lines.

[QUOTE=petrw1;152135]This does NOT appear to be the case for my account.[/QUOTE]

V4 credits? Those wouldn't be in the count either.

[QUOTE=Prime95;152138]V4 credits? Those wouldn't be in the count either.[/QUOTE]

Only 139 there:
[CODE]
v4-LL 110
v4-TF 29
[/CODE]

[quote=petrw1;152113]As expected each extra bit level about doubles the elapsed time ...

... with one exception:

From 64 to 65 bits my PIII time is almost quadruple 63 to 64 bits.
[code]
Bits P4 (Hrs) PIII (Hrs)
64 0.35 1.37
65 0.63 6.34[/code]Is this simply a result of 32 vs 64 bit architecture?[/quote]Not [I]simply[/I], but yes, there is a second-order 64-bit architecture effect.

Basically, on 32-bit architecture the registers used for integer arithmetic are 64 bits wide. Numbers less than 2[sup]64[/sup] can be operated-upon by a single integer instruction. When the numbers involved are greater than 2[sup]64[/sup], so that they are 65 or more bits long, integer arithmetic operations on them have to be performed by two or more instructions, _plus_ instructions for combining the 64-bit result parts (e.g., carries from the low-order part to the high-order part) appropriately.

So far, this is true regardless of whether the underlying architecture is "32-bit" or "64-bit", because it depends on the register width, not the bus width or address length. Perhaps the "64-bit" architecture enables 64-bit integer arithmetic registers to operate somewhat faster, but that wouldn't change the fact that a 65-bit number would require _at least_ two instructions for each integer arithmetic operation.

However, "64-bit" architecture probably has 128-bit-wide registers for integer arithmetic. This allows a 65-bit number to be handled in a single integer arithmetic operation instead of two or more, and thus eliminates the more-than-doubling number of instructions for numbers greater than 2[sup]64[/sup], compared to the instructions needed for numbers less than 2[sup]64[/sup].

So, you see a more-than-doubling jump in time when going past the 2[sup]64[/sup] size of numbers on 32-bit architecture that has 64-bit integer arithmetic registers (or on 64-bit architecture that has 64-bit registers), but not on 64-bit architecture that has 128-bit registers.

Formula to compute credit
 

Would it be possible to post the formula used to calculate the credit for the different types of assigments :
- TF factor found,
- TF no factor found,
- P-1 Factor found in stage 1,
- P-1 factor found in stage 2,
- P-1 no factor found,
- LL checks.

There are changes over the previous version.

Jacob

[QUOTE=S485122;152261]Would it be possible to post the formula used to calculate the credit for the different types of assigments[/QUOTE]I had asked that in [url=http://www.mersenneforum.org/showthread.php?t=10937]this thread[/url]... haven't received much response (yet?)

[QUOTE=Prime95;152090]The team web pages need a lot of work - they will improve over time. There is no way to change the password.[/QUOTE]

OK, then I'll wait some weeks before updating Team_Italia stats. :smile:

Though I was sure that some PW handling could be done from server side (like deleting a Team and recreating it). I'll be living with it, waiting to know which updates may be done from team pages.

Now, the last question:
3 - Once a user has joined a team, is it possible for the user to still see his personal stats ranking together with team stats ranking?

Don't bother to answer me if the answer has to do with the team pages work... :razz:

Thanks George!

Luigi

[QUOTE=S485122;152261]Would it be possible to post the formula used to calculate the credit for the different types of assigments :
- TF factor found,
- TF no factor found,
- P-1 Factor found in stage 1,
- P-1 factor found in stage 2,
- P-1 no factor found,
- LL checks.

There are changes over the previous version.[/QUOTE]

Hope you can read PHP code.

[QUOTE=Prime95;152280]Hope you can read PHP code.[/QUOTE]First time I read PHP but I think I can, especially with code that is so well documented. To be able to use that piece of code one needs access to the table "t_gimps_credit_timings".

And shouldn't the P-1 credit be the difference between the P-1 work already done and the reported work ? Or is that part of the code in another module ?

Jacob

[QUOTE=S485122;152286]
And shouldn't the P-1 credit be the difference between the P-1 work already done and the reported work ? Or is that part of the code in another module ?
[/QUOTE]

That's the cheesehead bug. You can pad your P-1 stats (until you're caught and I manually zero them :)

Remember P-1 is really only supposed to be done once.

[QUOTE=S485122;152286]To be able to use that piece of code one needs access to the table "t_gimps_credit_timings".[/QUOTE]

fftlen timing min_exponent max exponent
32 8.7840000000000003E-7 0 743
48 1.1399999999999999E-6 743 1099
64 1.4087999999999998E-6 1099 1469
80 0.0000017592 1469 1827
96 0.000002052 1827 2179
112 2.4623999999999999E-6 2179 2539
128 2.5271999999999997E-6 2539 2905
160 3.5639999999999997E-6 2905 3613
192 4.2935999999999999E-6 3613 4311
224 5.2511999999999998E-6 4311 5029
256 5.4743999999999996E-6 5029 5755
320 7.3439999999999995E-6 5755 7149
384 8.7839999999999992E-6 7149 8527
448 0.000010536 8527 9933
512 1.1327999999999999E-5 9933 11359
640 1.7039999999999999E-5 11359 14119
768 2.0591999999999999E-5 14119 16839
896 2.5415999999999999E-5 16839 19639
1024 2.7647999999999997E-5 19639 22477
1280 3.9119999999999998E-5 22477 27899
1536 4.7592000000000001E-5 27899 33289
1792 5.6879999999999998E-5 33289 38799
2048 6.1680000000000006E-5 38799 44339
2560 8.5199999999999997E-5 44339 55099
3072 1.0247999999999999E-4 55099 65729
3584 0.00012648 65729 76559
4096 1.2959999999999998E-4 76559 87549
5120 0.000192 87549 108800
6144 2.2559999999999998E-4 108800 129900
7168 2.7599999999999999E-4 129900 151300
8192 0.0002856 151300 172700
10240 3.9839999999999998E-4 172700 214400
12288 4.8479999999999997E-4 214400 255300
14336 5.9040000000000004E-4 255300 297300
16384 6.1439999999999997E-4 297300 340400
20480 8.3760000000000008E-4 340400 423300
24576 0.0010176 423300 504600
28672 1.2599999999999998E-3 504600 587500
32768 1.3127999999999998E-3 587500 671400
40960 1.7256000000000001E-3 671400 835200
49152 2.0951999999999998E-3 835200 995500
57344 2.5607999999999998E-3 995500 1158000
65536 2.7384000000000002E-3 1158000 1325000
81920 3.8592000000000001E-3 1325000 1648000
98304 4.6871999999999999E-3 1648000 1966000
114688 5.6808000000000006E-3 1966000 2287000
131072 5.9928000000000004E-3 2287000 2614000
163840 7.3535999999999992E-3 2614000 3251000
196608 9.0743999999999998E-3 3251000 3875000
229376 1.0775999999999999E-2 3875000 4512000
262144 1.1975999999999999E-2 4512000 5158000
327680 1.5311999999999999E-2 5158000 6421000
393216 1.8839999999999999E-2 6421000 7651000
458752 0.02256 7651000 8908000
524288 0.0252 8908000 10180000
655360 3.3264000000000002E-2 10180000 12650000
786432 4.1375999999999996E-2 12650000 15070000
917504 4.9200000000000001E-2 15070000 17550000
1048576 5.5920000000000004E-2 17550000 20050000
1310720 7.0080000000000003E-2 20050000 24930000
1572864 8.5919999999999996E-2 24930000 29690000
1835008 0.10224 29690000 34560000
2097152 0.11375999999999999 34560000 39500000
2621440 0.14999999999999999 39500000 49100000
3145728 0.18312 49100000 58520000
3670016 0.21839999999999998 58520000 68130000
4194304 0.24360000000000001 68130000 77910000
5242880 0.31295999999999996 77910000 96830000
6291456 0.37919999999999998 96830000 115300000
7340032 0.45839999999999997 115300000 134200000
8388608 0.504 134200000 153400000
10485760 0.67200000000000004 153400000 190700000
12582912 0.81120000000000003 190700000 227300000
14680064 0.98399999999999987 227300000 264600000
16777216 1.0800000000000001 264600000 302600000
20971520 1.4903999999999999 302600000 376100000
25165824 1.8215999999999999 376100000 448000000
29360128 2.1791999999999998 448000000 521500000
33554432 2.3832 521500000 596000000

[quote=cheesehead;151961]in this hard-for-me-to-read yellowish (or-greenish?) color. (I have red-green-color-deficient vision.)

hard-for-me-to-read color: "[SIZE=1][COLOR=#00ff00]!!At least one CPU is 90 days or more unreported and appears lost.[/COLOR][/SIZE]".

I'm using Firefox 3.0[/quote]I found the way to adjust text colors in Firefox, so will try to remember not to complain about colors again.

[QUOTE=1997rj7;151797]What happened to the Completed link that used to be in the Lifetime Stats section of your account report? Is there another way to see what has completed?[/QUOTE]I think this is a good reason to get rid of the menus completely. Firstly, they don't work without JS. Secondly, they hide links forcing people to click multiple times to find the link they really want. Thirdly, even with all the menus open it still doesn't fill an entire page height so they are not allowing people to see more that might otherwise "be lost" below the screen. Fourthly, after opening a menu item and clicking on a hidden (now exposed) link then the next page will collapse all the menus again (very annoying).

I wonder what problem was being solved by the addition of the collapsed menu items? I hope it wasn't only added just because it could be added (or maybe even because it "looked nicer?).

I vote to restore the fully expanded menus items (no JS please, it is just not necessary). With all the items shown it would much easier to find what one wants without having to click everywhere to expose links.

I like the expandable menus ... my choice though would be that one I open one it stays open. It seems to be hit-and-miss for me. I often want to check more than one stat in a group

[QUOTE=retina;152438]I vote to restore the fully expanded menus items (no JS please, it is just not necessary)[/QUOTE]I second the vote. For me personally, JS-enabled expanding JS menus would be just as good (as long as they remember what's open between pageloads), but as [i]retina[/i] says, there's no compelling reason to have the suboptions hidden at all.

My Christmas Wish List....
 

[QUOTE]Like any Christmas List you ask for the world knowing you will probably only get one thing or maybe something not even on the list. I know you have lots to do but I get the sense most of the critical stuff is getting addressed. And I am very happy with much of the new stuff and new look of V5. So if I may list my nice-to-haves: But I leave this all to your discretion. You don't have to rush an answer either.[/QUOTE]

Make all the stats pages into tables so that resizing, etc. keeps the data lined up and formatted. That is, the top-producers, Primenet Summary and Progress Reports. Sometimes the dividing lines get crooked; some text resizes but the extry boxes don't move/resize, and the up/down rank-change arrows don't move with the text so unless they are at default size, which is too small for my eyes, they are not next to the corresponding value.

And because many tables/lists are multi-page stop the heading lines from scrolling.

On the assignments page along with TF show the bit levels assigned.

From CPU Properties page have a link to Assignments or Results for the selected CPU.

Credit redistribution tool.

Let me "PING" my CPUs from the V5 server so I don't have to wait a day to see if they are dead and need to make a trip to restart them. (Or let me force a remote manual communication).

Either on the assignment page or via a tool show the expected points for an assignment.

I will echo someone else's suggestion for the ability to "request" a type of work and range of exponents or number of bits and if available and appropriate the server will assign them.

Some of the reports have a default report which can be quite long (i.e. Exponent Status or Factoring Limits). Let me choose the ranges before the report is displayed to save the server/network overhead and wait time.

Similar to the v4 benchmarks page let me choose a CPU type and exponent and have it estimate the run time.

When I sort the Exponent Status report by some other column and then by exponent again it gets all messed up.

why is there more tf credit for lower exponents than for higher exponents? (same bit level)
[quote]function credit_cpu_TF_no_factor( $exponent, $sf, $ef )
{
$est = 0.0;
for ( $i = $sf+1; $i <= $ef; $i++ ) {
if ($i < 48) continue;
$tf_timing = credit_get_TF_timing( $i );
$est += $tf_timing * (1 << ($i - 48)) * 1680.0 [B]/ $exponent[/B];
}
return $est;
}[/quote][SIZE=2]
[/SIZE][quote][SIZE=2]50847077[/SIZE][SIZE=2] no factor from 2^65 to 2^66[/SIZE][SIZE=2] 0.1470[/SIZE][SIZE=2]
[/SIZE][SIZE=2]332273099[/SIZE][SIZE=2] no factor from 2^65 to 2^66[/SIZE][SIZE=2] 0.0225[/SIZE][/quote]

[quote=starrynte;152680]why is there more tf credit for lower exponents than for higher exponents? (same bit level)
[SIZE=2]
[/SIZE][/quote]
Because candidate factors of mersenne numbers are of the form 2kp+1 where p is the exponent, so this series grows slower (more candidate factors to test per bit level) with smaller exponents than with larger exponents.

[QUOTE=Prime95;152124]Individual TF-LMH result lines are deleted before 365 days pass. This explains the discrepancy. I've added a footnote to the results report.[/QUOTE]

- The Account Summary Report still has the correct totals
- The total results count is about 100 low. Not sure if that is how many you deleted; if so then they are NOT being counted here.
- The GHz-Days reported on the Computer Details is NOT counting deleted results. My CPU doing all the TF-LMH which has results delete actually DROPPED about 4.4 (17.4 from 21.8) recently.

[QUOTE=petrw1;152688]
- The GHz-Days reported on the Computer Details is NOT counting deleted results. My CPU doing all the TF-LMH which has results delete actually DROPPED about 4.4 (17.4 from 21.8) recently.[/QUOTE]

Mind you, the first 100 LMH results were all .0009 each so 100 would only be 0.09 points not 4.4. Something is ODD here.

And it does NOT look like you have deleted any results of mine yet.

I have to do some detailed analysis to see where the 100 are missing from...stay tuned.

Trial factoring credit change
 

George wrote me the following after I discovered a discrepency between the code shown and the recent results I got :[code]The code was corrected several days ago to:

// Trial factoring needs a different timing table
// (or else hardwire the timings in PHP code):
//bits tf_timing
//---- ---------
//<=62 0.00465
//63-64 0.00743
//>=65 0.00707
function credit_get_TF_timing( $bits )
{
// will later move to table maybe so we don't maintain in code
if ( $bits <= 62 ) return (2.4*0.00465);
elseif ( $bits == 63 || $bits == 64 ) return (2.4*0.00743);
elseif ( $bits >= 65 ) return (2.4*0.00707);
}[/code]By several days ago on must understand between the 20th of November 2008 and the second of December 2008.

Jacob

George, a feature request. Would it be possible to get the exponent status for exponents currently assigned to one? At the moment we can only check the exponents one by one. This can be tiresome as for example I do not want to doublecheck any exponents that were tested the first time by Ars Technica Team Prime Rib. Or if someone else returns a first time result for a 24M that I have been assigned, I don't want to run an LL test and want to release it.

I have three suggestions on how this might be accomplished.

1) Create an interface where a file containing a list of exponents and nothing else is uploaded and the status of all those exponents is returned.
2) Create a link to each exponent in the assignments list which takes you to the exponent status page of that exponent.
3) Create a new page within accounts that gives the status for all assigned exponents - probably the easiest solution as it requires one extra SQL query.

Thanks!

[QUOTE=S485122;152286]To be able to use that piece of code one needs access to the table "t_gimps_credit_timings"[/QUOTE]Here is my reworked version of credit_get_FFT_timing() that incorporates the lookup table ([url=http://www.mersenneforum.org/showpost.php?p=152289&postcount=207]George's post #207[/url]) into itself, if it's of any use to anyone.[code]function credit_get_FFT_timing($exponent=0, $fftlen=0) {
static $fft_lookup_table = array();
if (empty($fft_lookup_table)) {
//$fft_lookup_table[FFTSIZE] = array(TIMING, MIN_EXPONENT, MAX_EXPONENT);
$fft_lookup_table[32] = array(8.7840E-7, 0, 743);
$fft_lookup_table[48] = array(1.1400E-6, 743, 1099);
$fft_lookup_table[64] = array(1.4088E-6, 1099, 1469);
$fft_lookup_table[80] = array(1.7592E-6, 1469, 1827);
$fft_lookup_table[96] = array(2.0520E-6, 1827, 2179);
$fft_lookup_table[112] = array(2.4624E-6, 2179, 2539);
$fft_lookup_table[128] = array(2.5272E-6, 2539, 2905);
$fft_lookup_table[160] = array(3.5640E-6, 2905, 3613);
$fft_lookup_table[192] = array(4.2936E-6, 3613, 4311);
$fft_lookup_table[224] = array(5.2512E-6, 4311, 5029);
$fft_lookup_table[256] = array(5.4744E-6, 5029, 5755);
$fft_lookup_table[320] = array(7.3440E-6, 5755, 7149);
$fft_lookup_table[384] = array(8.7840E-6, 7149, 8527);
$fft_lookup_table[448] = array(1.0536E-5, 8527, 9933);
$fft_lookup_table[512] = array(1.1328E-5, 9933, 11359);
$fft_lookup_table[640] = array(1.7040E-5, 11359, 14119);
$fft_lookup_table[768] = array(2.0592E-5, 14119, 16839);
$fft_lookup_table[896] = array(2.5416E-5, 16839, 19639);
$fft_lookup_table[1024] = array(2.7648E-5, 19639, 22477);
$fft_lookup_table[1280] = array(3.9120E-5, 22477, 27899);
$fft_lookup_table[1536] = array(4.7592E-5, 27899, 33289);
$fft_lookup_table[1792] = array(5.6880E-5, 33289, 38799);
$fft_lookup_table[2048] = array(6.1680E-5, 38799, 44339);
$fft_lookup_table[2560] = array(8.5200E-5, 44339, 55099);
$fft_lookup_table[3072] = array(1.0248E-4, 55099, 65729);
$fft_lookup_table[3584] = array(1.2648E-4, 65729, 76559);
$fft_lookup_table[4096] = array(1.2960E-4, 76559, 87549);
$fft_lookup_table[5120] = array(1.9200E-4, 87549, 108800);
$fft_lookup_table[6144] = array(2.2560E-4, 108800, 129900);
$fft_lookup_table[7168] = array(2.7600E-4, 129900, 151300);
$fft_lookup_table[8192] = array(2.8560E-4, 151300, 172700);
$fft_lookup_table[10240] = array(3.9840E-4, 172700, 214400);
$fft_lookup_table[12288] = array(4.8480E-4, 214400, 255300);
$fft_lookup_table[14336] = array(5.9040E-4, 255300, 297300);
$fft_lookup_table[16384] = array(6.1440E-4, 297300, 340400);
$fft_lookup_table[20480] = array(8.3760E-4, 340400, 423300);
$fft_lookup_table[24576] = array(1.0176E-3, 423300, 504600);
$fft_lookup_table[28672] = array(1.2600E-3, 504600, 587500);
$fft_lookup_table[32768] = array(1.3128E-3, 587500, 671400);
$fft_lookup_table[40960] = array(1.7256E-3, 671400, 835200);
$fft_lookup_table[49152] = array(2.0952E-3, 835200, 995500);
$fft_lookup_table[57344] = array(2.5608E-3, 995500, 1158000);
$fft_lookup_table[65536] = array(2.7384E-3, 1158000, 1325000);
$fft_lookup_table[81920] = array(3.8592E-3, 1325000, 1648000);
$fft_lookup_table[98304] = array(4.6872E-3, 1648000, 1966000);
$fft_lookup_table[114688] = array(5.6808E-3, 1966000, 2287000);
$fft_lookup_table[131072] = array(5.9928E-3, 2287000, 2614000);
$fft_lookup_table[163840] = array(7.3536E-3, 2614000, 3251000);
$fft_lookup_table[196608] = array(9.0744E-3, 3251000, 3875000);
$fft_lookup_table[229376] = array(1.0776E-2, 3875000, 4512000);
$fft_lookup_table[262144] = array(1.1976E-2, 4512000, 5158000);
$fft_lookup_table[327680] = array(1.5312E-2, 5158000, 6421000);
$fft_lookup_table[393216] = array(1.8840E-2, 6421000, 7651000);
$fft_lookup_table[458752] = array(2.2560E-2, 7651000, 8908000);
$fft_lookup_table[524288] = array(2.5200E-2, 8908000, 10180000);
$fft_lookup_table[655360] = array(3.3264E-2, 10180000, 12650000);
$fft_lookup_table[786432] = array(4.1376E-2, 12650000, 15070000);
$fft_lookup_table[917504] = array(4.9200E-2, 15070000, 17550000);
$fft_lookup_table[1048576] = array(5.5920E-2, 17550000, 20050000);
$fft_lookup_table[1310720] = array(7.0080E-2, 20050000, 24930000);
$fft_lookup_table[1572864] = array(8.5920E-2, 24930000, 29690000);
$fft_lookup_table[1835008] = array(1.0224E-1, 29690000, 34560000);
$fft_lookup_table[2097152] = array(1.1376E-1, 34560000, 39500000);
$fft_lookup_table[2621440] = array(1.5000E-1, 39500000, 49100000);
$fft_lookup_table[3145728] = array(1.8312E-1, 49100000, 58520000);
$fft_lookup_table[3670016] = array(2.1840E-1, 58520000, 68130000);
$fft_lookup_table[4194304] = array(2.4360E-1, 68130000, 77910000);
$fft_lookup_table[5242880] = array(3.1296E-1, 77910000, 96830000);
$fft_lookup_table[6291456] = array(3.7920E-1, 96830000, 115300000);
$fft_lookup_table[7340032] = array(4.5840E-1, 115300000, 134200000);
$fft_lookup_table[8388608] = array(5.0400E-1, 134200000, 153400000);
$fft_lookup_table[10485760] = array(6.7200E-1, 153400000, 190700000);
$fft_lookup_table[12582912] = array(8.1120E-1, 190700000, 227300000);
$fft_lookup_table[14680064] = array(9.8400E-1, 227300000, 264600000);
$fft_lookup_table[16777216] = array(1.0800E-0, 264600000, 302600000);
$fft_lookup_table[20971520] = array(1.4904E-0, 302600000, 376100000);
$fft_lookup_table[25165824] = array(1.8216E-0, 376100000, 448000000);
$fft_lookup_table[29360128] = array(2.1792E-0, 448000000, 521500000);
$fft_lookup_table[33554432] = array(2.3832E-0, 521500000, 596000000);
}
if ($fftlen && isset($fft_lookup_table[$fftlen])) {
return $fft_lookup_table[$fftlen][0];
}
if ($exponent) {
foreach ($fft_lookup_table as $fftlen => $dataarray) {
if (($exponent >= $dataarray[1]) && ($exponent <= $dataarray[2])) {
return $dataarray[0];
}
}
}
return null;
}
[/code]

[QUOTE=garo;152725]Would it be possible to get the exponent status for exponents currently assigned to one? [/QUOTE]

Sometimes I'm too nice. The exponent status page will now do this. As a bonus if you edit the URL and replace user=1 with team=1 it will show the status of exponents currently assigned to your team.

:bow::bow::bow:

We are not worthy!

Even though we are indeed not worthy, I'll make a low-priority title-change request:

On the Factoring Effort report ("Factoring Limits" under "Results Queries"), extend the title

"PrimeNet Factoring Effort on Mersenne Numbers"

to be

"PrimeNet Factoring Effort on Mersenne Numbers for which no factor is known"

to hint at why some exponents -- the ones for which factors been found -- are not listed

[quote]The exponent status page will now do this.[/quote]:D:D:D (i like how it only queries the assignments in your workload only)

[QUOTE=petrw1;152695]Mind you, the first 100 LMH results were all .0009 each so 100 would only be 0.09 points not 4.4. Something is ODD here.

And it does NOT look like you have deleted any results of mine yet.

I have to do some detailed analysis to see where the 100 are missing from...stay tuned.[/QUOTE]

Appears to be my mistake on the points total :redface: I recalculated all the results (there are NONE missing yet) and I do get a total within 0.05 of your total (I chalk that up to rounding as I only have access to 4 digits of points.)

However, still not sure why the Results Lifetime and 365 days summary shows 1,600 more results than I really have.

[QUOTE=Prime95;152280]Hope you can read PHP code.[/QUOTE]Hi George, I believe I have found a bug in your code :surprised
It shouldn't affect much in the near future, but...

The problem is that PHP integers are 32bit-signed. Which is fine most of the time, but you get into problems when bitshifting large values. Such as this line:[code]$est += $tf_timing * (1 << ($i - 48)) * 1680.0 / $exponent;[/code]Once $i gets to 79 you end up with negative values and [i]credit_cpu_TF_no_factor()[/i] will return approximately zero when calculating TF to 2^79. The quick-and-easy fix is to change your bitshift to a call to PHP's [url=http://php.net/pow]pow()[/url] function which will typecast to float as needed:[code]$est += $tf_timing * pow(2, ($i - 48)) * 1680.0 / $exponent;[/code]I don't know if anyone has returned factoring results for 2^79 or 2^80 yet (by default exponents > M420400000), if so please check what they were credited as, it's likely wrong.

[QUOTE=James Heinrich;153207]I don't know if anyone has returned factoring results for 2^79 or 2^80 yet, if so please check what they were credited as, it's likely wrong.[/QUOTE]

Fixed last week. Yes, someone did TF one exponent to 2^79 only to get -100 GHz days.

[QUOTE=petrw1;151897]COOL!!! Worked great for me ... even merging 3 into 1 (in two passes of two).

[/QUOTE]

Not sure it will be safe to merge these two:
[CODE]
Jessie Intel Pentium 4 2.40GHz
GUID C0455DED94A2996003B6CAD901BDB92F
Windows,Prime95,v25.7,build 3 2.394 2008-12-16 19:01 T 52.2420 TF 26547371 LL LL, 85.20% 2008-12-19 17:36 2008-12-16 19:00 50 3

Jessie Intel Pentium 4 2.40GHz
GUID C0455DED94A2996003B6CAD901BDB92F
Windows,Prime95,v25.7,build 3 2.394 2008-12-16 19:01 T 52.2420 TF 59107781 TF 0.00% 2008-12-19 17:36 2008-11-12 13:32 36 3 [/CODE]

This CPU was never involved in a duplicate until today. HOWEVER, unlike the others they are virtally identical except for the current assignment which, by the way, in the second case actually belongs to James Hintz.
They even have the same GUID.

My fear is that if I merge them the points will be added and therefore duplicated.

PLEASE ADVISE....

P.S. My Quad still shows up as a second entry as a PIII Xeon after each reboot. I'll see if 25.8.4 fixes that. I can and do merge them when this happens but it resets my Reliability/Confidence numbers so I will never get 'preferred' assignments.

This is a bug in the CPUs web page. Don't try to merge them - they are the same CPU.

FIXED....
 

[QUOTE=Prime95;153627]This is a bug in the CPUs web page. Don't try to merge them - they are the same CPU.[/QUOTE]

Duplicate is gone now.
Thanks

Could we possibly have a feature added to the Manual Testing assignment page to let us request a specific assignment? I know that this can already be done with a PrimeNet-connected client (that is, by entering an assignment into worktodo.txt manually, and then next time the client communicates with the server if reserves the assignment if it's not already reserved by someone else), but there is currently no such way to do this for manual testing.

Over in the LMH subforum, in the "65.1M-66.0M to 2^64" thread at [URL]http://www.mersenneforum.org/showthread.php?t=11159[/URL], mdettweiler made a new-feature suggestion (a way to request manual assignments of a specific range of exponents, but skipping exponents already assigned to others) [I](edit: there it is just above here)[/I] that ties right in with something I was thinking about earlier:

Here's the way I described my proposal in the "LL vs. DC ... am I reading this right?" thread at [URL]http://www.mersenneforum.org/showpost.php?p=151166&postcount=5[/URL]

[quote=cheesehead;151166]Proposal:

A new PrimeNet function, [I]conditional specific assignments[/I].

A conditional specific assignment would be requested by someone _for a specific exponent_ and type of assignment (TF, P-1, L-L, DC ...). Then PrimeNet would:

if that exponent was not currently assigned to anyone else (for any purpose), then assign it as requested (and return a code indicating that success),

else

return a code indicating that the conditional assignment request was refused.

(Exponents in ranges not currently available for assignment would be in the latter category.)

The refusal return code could be elaborated:

the exponent was already assigned to someone else for some purpose,

the exponent previously had been L-Led (first-time or later) by the requestor of a conditional L-L assignment -- to prevent two L-L test assignments to the same person on an exponent,

the exponent is already assigned to the (apparently forgetful) requestor :-),

range not currently available for assignment,

and so on.

This wouldn't [I]prevent[/I] anyone from doing whatever they can do now, such as performing two L-Ls on the same exponent or doing a test on an exponent currently assigned to someone else; it would just provide folks a better means to avoid doing so accidentally or unknowingly, by cooperating with PrimeNet instead of going around it by perusing a report then forcing a manual communication to squat on an exponent (hoping that PrimeNet had not assigned it since the report's epoch, but not having any assurance of that).[/quote]Now, PrimeNet already does something like that internally, but what we're proposing is to make it explicitly external on the Manual Assignments page.

While my proposal above is about single exponents, it could be extended to a range of exponents, I think. The stuff about return codes isn't essential.

[QUOTE=cheesehead;154105]PrimeNet already does something like that internally, but what we're proposing is to make it explicitly external on the Manual Assignments page.[/QUOTE]

It has been on my to do list for a long while. I'll bump up its priority.

a nice feature would be to, through primenet, be able to force a computer in your account (even better, a computer in your team, though this may cause security issues) to update itself.

[QUOTE=starrynte;154317]a nice feature would be to, through primenet, be able to force a computer in your account (even better, a computer in your team, though this may cause security issues) to update itself.[/QUOTE]That would be a security nightmare. I hate to think what happens when someone works out how to "update" everyone's PCs with their own malicious code by using the Prime95 autoupdate "feature". No Thanks.

true, in that case no

Is there any way to drop the "manual testing" cpu and "v4_computers" without losing their credit? The two extra cpu's in the team cpu's list is a bit confusing at first, until you see that they are manual testing and v4_computers
(I've upgraded all my computers from 24.14 already, so v4_computers "cpu" is now useless)

[QUOTE=starrynte;154426]Is there any way to drop the "manual testing" cpu and "v4_computers" without losing their credit? The two extra cpu's in the team cpu's list is a bit confusing at first, until you see that they are manual testing and v4_computers
(I've upgraded all my computers from 24.14 already, so v4_computers "cpu" is now useless)[/QUOTE]

Someone can correct me, but my understanding is that the "coming soon" credit redistribution tool on the v4 migration page will address this, though maybe just for the v4_computers.

When an assignment finishes while the Assignment Details page is loading, the latter will display a line for exponent 0 with Core: 0, Assigned: 1900-01-01 00:00, Updated: 1900-01-01 00:00 instead of the former.

Now since the Assignment Details page takes quite a while to load with 11,000+ assignments of only a few minutes each, on average, this isn't exactly a rare occurance...

[QUOTE=ckdo;154673]Now since the Assignment Details page takes quite a while to load with 11,000+ assignments of only a few minutes each, on average, this isn't exactly a rare occurance...[/QUOTE]

Wow...and I thought 200 assignments was a lot to manage.

"Few minutes each...." sound like you are doing a lot of TF or TF-LMH.

Over 40,000 CPUs registered to V5
 

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

V4 had about 70 - 75,000 but "many" were long since inactive. Not sure who can define "many" in this context.

[SIZE=1][B]Members[/B][/SIZE] [SIZE=1][B]Most Recent Activity[/B][/SIZE] [SIZE=1][B]Least Recently Activity[/B][/SIZE] [SIZE=1]5[/SIZE] [SIZE=1]2008-10-25 20:09[/SIZE] [SIZE=1]2008-12-25 06:24 [/SIZE]shouldn't the most recent activity and least recently [sic] activity dates be swapped?

[quote=starrynte;154992]shouldn't the most recent activity and least recently [sic] activity dates be swapped?[/quote]

Ummm... Nope?

Report showing weird display
 

See attached.

[QUOTE=S485122;155007]Just look at the time on your display. You ran the query on the hour while the server was updating the files...[/QUOTE]Nope, I accessed that page only ~5 minutes before posting it here. And I refreshed it a few times to make sure it was not a fluke. It stayed exactly like that each time so I reported it here.

[edit]
I tried it again just now and it is still messed up, although a little bit differently than before, but still not correct.

[size=1]Hey, what happened to the post I quoted? Now it looks like I replied to a ghost.[/size]

I had posted without verifying. You were right. I was wrong. But I only realised that afterwards. So I deleted my post (this is possible during edit time.) But not quickly enough to prevent you from catching me :-(
Jacob

[quote=starrynte;154992][SIZE=1][B]Members[/B][/SIZE] [SIZE=1][B]Most Recent Activity[/B][/SIZE] [SIZE=1][B]Least Recently Activity[/B][/SIZE] [SIZE=1]5[/SIZE] [SIZE=1]2008-10-25 20:09[/SIZE] [SIZE=1]2008-12-25 06:24[/SIZE][/quote]
To clarify, 2008-10-25 is the "Most Recent Activity" and 2008-12-25 is the "Least Recently Activity"?

I have noticed a problem with my user account report.
I have a machine with quite a few LMH numbers up in the 100Mdigit range. My report showed them as being assigned LL. I checked the worktodo.txt, there were no such LL's. I unreserved them from the webpage, now a different CPU's TF's are showing as LL's!

current example:
[code]spudboy2 1 332198689 LL 0.00% 2008-10-05 16:08 82 2008-12-17 17:21 2009-01-14 17:21 2009-01-17 05:43 22
spudboy2 1 332198809 LL 0.00% 2008-10-05 16:08 82 2008-12-17 17:21 2009-01-14 17:21 2009-01-17 20:19 22
[/code]

Test / Status... very slow with P-1 running
 

I have a Q9550: 3 cores doing LL and 1 core doing P-1.

When I click Test / Status... it literally takes 15 seconds to respond.
If I change it to running LL only Status... responds instantly.

On a related note the estimated completion dates for the LL tests change quite a bit when I stop the P-1 running and have all 4 cores on LL. About a day is ADDED (from Jan 1 to Jan 2 ... same hour) even though the per-iteration times actually drop slightly. The estimates are MORE accurate when P-1 is running on 1 core.

[quote=petrw1;155304]
When I click Test / Status... it literally takes 15 seconds to respond.
If I change it to running LL only Status... responds instantly.[/quote]
Same here, though only about 8 seconds on my computer

[QUOTE=petrw1;155304]I have a Q9550: 3 cores doing LL and 1 core doing P-1.

When I click Test / Status... it literally takes 15 seconds to respond..[/QUOTE]

I presume P-1 is doing stage 2. I'd reduce the amount of memory prime95 is allowed to use. I'd guess its taking 15 seconds to page in a lot of stuff (both prime95 code as well as OS code and data).

I have also seen something of this sluggishness on a couple of my systems. On my AMD X2 (currently a dedicated Prime95 rig for the rest of 2008) I've got it running P-1 in 1800MB of 2GB installed memory, so the entire OS is paged; any attempt to open menus or windows or such results in a churning of the HDD. That's easily understood. On my Q6600, if I structure my work assignments such that CPU usage stays at 100% then the system is sluggish, programs take a long time to load, videos don't play back smoothly, etc). If I stop a worker then everything is lightning fast (hooray for [i]PauseWhileRunning[/i]!). If I structure the workload so it's somewhat inefficient and runs at 95% CPU load then responsiveness is pretty good.

I think your ([i]petrw1[/i]) problem is probably a combination of both paging (if it's more of a problem in stage2 of P-1, and/or you're using a significant portion of your RAM for P-1), and memory bandwidth saturation. I believe (someone will doubtlessly correct me) in terms of bandwidth use, worktypes would rank P-1 (high), ECM (high), LL (medium), TF (low).

[quote=Prime95;155315]I presume P-1 is doing stage 2. I'd reduce the amount of memory prime95 is allowed to use. I'd guess its taking 15 seconds to page in a lot of stuff (both prime95 code as well as OS code and data).[/quote]

That's unlikely.

I have a Q6600 running mprime 25.8.4 (-m switch) which currently has 3000+ assignments, including 100+ P-1 ones.

I have that machine on manual communication. If I select to get the expected completion dates it takes a whopping 6 minutes, even right after startup (i.e. before any worker has been started). If comment out the P-1 assignments in worktodo.txt, it only takes a few seconds. qed.

What makes the situation worse is that with automatic communication the expected completion dates are recalculated whenever an assignment finishes, which is usually more often than those 6 minutes. That means the comm thread runs into an infinite loop - the "Done communicating with server" line does not appear for hours or even days unless you stop all workers, in which case it will appear said 6 minutes later.

This entire recalculation issue happens even with NoMoreWork=1. What's the point of calculating expected completion dates time and again unless you want to send them to the server, display them, or request more work?

To cut a long story short... had I not set ManualComm=1 the machine would recompute expected completion dates more or less 24/7, wasting half a core of crunching power in the process.

Some effort should be made to either speed up the calculation or at least make it happen less often. E.g. with DaysOfWork=90 there's no particular need to check whether more work needs to be reserved, every few minutes. Once a day should be more than enough, IMHO.

[QUOTE=Prime95;155315]I presume P-1 is doing stage 2. I'd reduce the amount of memory prime95 is allowed to use. I'd guess its taking 15 seconds to page in a lot of stuff (both prime95 code as well as OS code and data).[/QUOTE]

I'm pretty sure it is either stage but I could double check.
I have 2G allocated

[QUOTE=ckdo;155336]which currently has 3000+ assignments.[/QUOTE]

Non-standard usage may well result in non-standard issues. Is there any particular reason you want to have 3000 active assignments?

[quote=petrw1;155363]I'm pretty sure it is either stage but I could double check.
I have 2G allocated[/quote]
Mine is in stage 1 and it takes (corrected) 4 seconds so probably in either stage

[quote=ckdo;155336]If comment out ... assignments in worktodo.txt[/quote]
How? (I would like to do so on some of my exponents which are expected to complete in months, to hopefully decrease time needed to calculate completion dates)

I updated a computer last night at a buddies and for some reason it is now showing twice in my account. I have tried to get it to merge but when I try I get the following message:

CPU 58edf390c255c13cd94b08b7fb35deb6 reported results after CPU 62cbbeddf7068de3fc607680806580aa was created

What can I do?

[QUOTE=Bundu;155747]I updated a computer last night at a buddies and for some reason it is now showing twice in my account.

What can I do?[/QUOTE]

First, send me the prime.log file.

[QUOTE=Bundu;155747]I updated a computer last night at a buddies and for some reason it is now showing twice in my account. I have tried to get it to merge but when I try I get the following message:

CPU 58edf390c255c13cd94b08b7fb35deb6 reported results after CPU 62cbbeddf7068de3fc607680806580aa was created

What can I do?[/QUOTE]

Same thing happened to me a couple months ago when I reinstalled XP on a machine. George's answer was that somehow in the reinstall process XP give the CPU and new ID. No problem, I just merged the CPUs and the problem is history.

50,000 CPUs
 

[QUOTE=petrw1;154815][CODE]
Today's Numbers (That was on Dec 23)
Teams 121
Users 5791
CPUs 40240
TFLOP/s 38.349
GHz-Days 19174.259 [/CODE]

[CODE]Today's Numbers
Teams 132
Users 7667
CPUs 50001
TFLOP/s 37.974
GHz-Days 18986.851 [/CODE]

Interesting 3 weeks later; 10,000 more CPUs but the thruput numbers are slightly lower.

[QUOTE=petrw1;158782]Interesting 3 weeks later; 10,000 more CPUs but the thruput numbers are slightly lower.[/QUOTE]

I'll throw out the suggestion that this implies that virtually all the "new" CPUs are actually V4_Computers being converted to V5 and with that the Thruput is simply moving from the V4 bucket to the actual CPUs.

Moving assignments between CPUs
 

If I want to move some assignments from one CPU to another is the preferred method to:

A. Put the exponents in Worktodo.Add on the destination CPU and once added successfully delete the lines from source CPU Worktodo.txt (will this second part happen automatically too?)

B. Cut and paste the WorkToDo.txt lines from the source to destination

C. Other?? _________________________

Option B is best. Option A will not work because the exponents are already registered with the server, so the 2nd computer cannot re-register them.

-- monst

[QUOTE=monst;159422]Option B is best. Option A will not work because the exponents are already registered with the server, so the 2nd computer cannot re-register them.

-- monst[/QUOTE]

Thanks ... and more precisely so as not to upset the server would I:

a. Add the assignments to the destination CPU.
b. Do a manual communication, expecting the server to show them assigned to the destination CPU. Or will they show up as assigned to both until step d?
c. Delete them from the source CPU
d. Do a manual communication.

Why is it that there are over 8000 users but in the producers list (which goes all the way down to 0.000 GHz-days) I'm ranked out of just 2845 people? Does this mean that 5155 people haven't yet switched to the v5 server? Why is it taking them so long to upgrade? I know some people have many computers (aka curtisc) but this seems like a lot. Don't they ever check their machines!? Also, why is "anonymous" listed repeatedly in the producers list? I thought the #1 ranked "anonymous" accounted for all those that had yet to switch. Yes, I'm just bored.

[quote=stars10250;159440]Also, why is "anonymous" listed repeatedly in the producers list? I thought the #1 ranked "anonymous" accounted for all those that had yet to switch.[/quote]
Those who haven't updated their v4 accounts to v5 are lumped together as one big anonymous entry. Those who have neither v4 nor v5 accounts get their own unique anonymous entry.

[QUOTE=stars10250;159440]Why is it that there are over 8000 users but in the producers list (which goes all the way down to 0.000 GHz-days) I'm ranked out of just 2845 people? Does this mean that 5155 people haven't yet switched to the v5 server? Why is it taking them so long to upgrade? I know some people have many computers (aka curtisc) but this seems like a lot. Don't they ever check their machines!? Also, why is "anonymous" listed repeatedly in the producers list? I thought the #1 ranked "anonymous" accounted for all those that had yet to switch. Yes, I'm just bored.[/QUOTE]

I can answer your last question first because I asked the same one a while back: The "ANONYMOUS" at the top of the list is the unclaimed v4 credit. It will disappear from the report Oct 20, 2009 (1 years after the big crash - not the Stock Market Crash). The rest of them are people who chose to NOT put a name when they registered so they are truly "anonymous".

I believe the 8000 users are all V5 users. As to why there are only 2845 in the standings, I wondered the same thing today actually. My guess is that the other 5155 have not submitted a result yet...though that seems like a high percentage. On the page: [B][url]http://www.mersenne.org/primenet/[/url][/B]
on the top right is the chart: Recently Active and Work Done. For 30 days it has the count 3437. I interpret this as meaning that some of these 3437 only reported as active but did NOT submit a result yet so 2845 results may be reasonable.

As to how many v4 users have yet to convert (or finish converting):
- some never will: i.e. they quit long before, or in some cases right after Oct 20.
- The "ANONYMOUS" points is almost 40% of ALL points; but it is dropping which means they are still being converted. Enough that the points converted out is more than the points still being contributed by those not yet converted.
- I found a post from shortly before the crash that indicated there were about 70,000 computers registered. Again, some will never be converted. We now have over 52,000 and the number is still rising; however the daily thruput is almost constant. This suggests to me that most of "new" computers are V4 computers still being converted; thereby migrating the thruput from ANONYMOUS to a v5 computer.

And if you truly are bored you can still get at the Team_Prime_Rib standings report from Oct 20; determine from the 90 day results how many "probably" quit before then; determine what their v5 points total would be and therefore get a rough idea how much of ANONYMOUS will never convert.

[QUOTE=petrw1;159426]Thanks ... and more precisely so as not to upset the server would I:

a. Add the assignments to the destination CPU.
b. Do a manual communication, expecting the server to show them assigned to the destination CPU. Or will they show up as assigned to both until step d?
c. Delete them from the source CPU
d. Do a manual communication.[/QUOTE]

It would appear this works AND the answer to the last question in b. is NO: The man.comm. on the destination CPU makes the assignments show as the moved exponent belonging to the destination only.

[QUOTE=petrw1;158782][QUOTE=petrw1;154815][CODE]
Today's Numbers (That was on Dec 23)
Teams 121
Users 5791
CPUs 40240
TFLOP/s 38.349
GHz-Days 19174.259 [/CODE]

[CODE]Today's Numbers - Jan 15,2009.
Teams 132
Users 7667
CPUs 50001
TFLOP/s 37.974
GHz-Days 18986.851 [/CODE]

Interesting 3 weeks later; 10,000 more CPUs but the thruput numbers are slightly lower.[/QUOTE]

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

3 more weeks; 10,000 more CPUs...HOWEVER...thruput is now up by over 10%. :fusion:
This is not a one-time. In fact TFLOP/s has been in the 42-44 range every time I looked over the last week. IMHO this means we are now seeing NEW members and not just V4-V5 conversions.

Major exprirations??? or Drop-out??? or error???
 

Hundreds of lower DC and Thousands of lower LL, TF and PM assignments suddenly available?

[quote=petrw1;161616]Hundreds of lower DC and Thousands of lower LL, TF and PM assignments suddenly available?[/quote]

[quote=Prime95;152303]All exponents assigned by the v4 server prior to Oct. 20 that were not currently assigned and have not had an LL result reported since Oct 20 have now been reserved by anonymous. I doubt many of these will be completed by the v4 client, however they now 90 days to contact the server and avoid expiration.

All manual reserved exponents (by email) have now been reserved by anonymous for one year.

The problem with the v5 server not unreserving some v4 exponents when an LL result is reported is not fixed. Frankly, the transferred v4 assignments are a mess. It is easier for me to just let the dust settle and have the normal expiration policies clean up the mess. If your assignments web report shows some active v4 assignments that you know you have completed, then feel free to manually unreserve them (or not - they'll expire eventually).

The good news? The server is now handing out much smaller exponents for testing, double-checking![/quote]

The 90 days are over today...

Actually it's been 60 days since December 4th (or thereabouts), when all of the legacy v4 reservations were put back under the expiration system. Is there any reason we thought it would be 90 days instead of 60?

[quote=Kevin;161636]Actually it's been 60 days since December 4th (or thereabouts), when all of the legacy v4 reservations were put back under the expiration system. Is there any reason we thought it would be 90 days instead of 60?[/quote]

George said 90 days in his post quoted above but looks like he implemented 60 days.

A related problem I have with the server reports is that they do not show days to expiry on your current exponent list.

[quote=garo;161652]A related problem I have with the server reports is that they do not show days to expiry on your current exponent list.[/quote]

I would like that feature back as well.

[QUOTE=garo;161652]A related problem I have with the server reports is that they do not show days to expiry on your current exponent list.[/QUOTE]

I don't mean to sound like a smart aleck but isn't it just a matter of checking if the "Last Update" date is more than 60 days ago?

[quote=petrw1;161716]I don't mean to sound like a smart aleck but isn't it just a matter of checking if the "Last Update" date is more than 60 days ago?[/quote]Such trusting faith in software :-) ... (But keep showing us that fresh viewpoint! It's valuable to counteract the clouding of vision that experience has brought to some of us. Sincerely!)

The questions are ... [I]is[/I] the relevant interval 60 days? ... or 90? ... or 180? And why do [I]we[/I] have to do the calendar arithmetic when PrimeNet is capable of doing that in microseconds?

What we really want to know is what date [I]PrimeNet[/I] considers the expiry date to be, according to whatever formula it is actually using (see post #273 for apparent discrepancy between what George wrote and what PrimeNet is doing), so it needs to be explicitly reported by PrimeNet to us.

- - -

BTW, regarding necessary mistrust associated with computers:

[URL]http://tech.yahoo.com/blogs/null/118488[/URL]

[quote=petrw1;161716]I don't mean to sound like a smart aleck but isn't it just a matter of checking if the "Last Update" date is more than 60 days ago?[/quote]
Another way that I've found is to go to the Manual Testing>Manual Extensions page. It shows essentially all of the same information that the Assignments page shows, along with the days to expiry. :smile:

[quote=mdettweiler;161726]Another way that I've found is to go to the Manual Testing>Manual Extensions page. It shows essentially all of the same information that the Assignments page shows, along with the days to expiry. :smile:[/quote]

Thanks, that does indeed show the days to expiration.

Adding to worktodo in p95v259
 

How do I add work to my worktodo file? My old computer's hard drive died so I don't have access to the old file.

[QUOTE=petrw1;161581]
This is not a one-time. In fact TFLOP/s has been in the 42-44 range every time I looked over the last week. IMHO this means we are now seeing NEW members and not just V4-V5 conversions.[/QUOTE]

I'm only seeing 37.027 TFLOP/s in the last 24 hours, 39.941 in the last week and 38.742 in the last 30 days.

Perhaps you looked at potential TFLOP/s instead of actual?

[QUOTE=jinydu;162146]I'm only seeing 37.027 TFLOP/s in the last 24 hours, 39.941 in the last week and 38.742 in the last 30 days.

Perhaps you looked at potential TFLOP/s instead of actual?[/QUOTE]

I was looking at Today's Numbers in the menu on the lower-left of most screens and yes for the last couple days it has been lower again....so maybe I spoke too soon

Adding to worktodo in p95v259
 

[QUOTE=dominicanpapi82;162117]How do I add work to my worktodo file? My old computer's hard drive died so I don't have access to the old file.[/QUOTE]There are two ways of doing it :

- Stop and exit Prime95, edit the files and restart Prime95. (This is necessary if you want to reorder worktodo.txt, change parameters in local.txt or prime.txt.)

- Create a worktodo.add file withe the same structure as worktodo.txt ("[Worker #N]" header, followed by different workunit lines.) After a while the worktodo.add file will be absorbed by Prime95 and its workunits appended to the existing work.

There are some issues when transferring workunits from one computer to another : the ID changes, and sometimes both the lines with the old assignment ID and the new assignment ID stay in the file. This is something George should investigate when he is back from hollidays and has some spare time...

Jacob

OVER 10,000 Users!!!!
 

If I am interpreting it correctly based on the "Overall Standings" 3,324 have submitted results ... so far; I know there will be many working away but just haven't finished an assignment yet, especially if it is a large LL.

[CODE]
Today's Numbers
Teams 155
Users 10033
CPUs 63194
TFLOP/s 39.462
GHz-Days 19730.932 [/CODE]

[QUOTE=Prime95;154138]It has been on my to do list for a long while. I'll bump up its priority.[/QUOTE]

The ability to request exponents in a specified range of the Manual
Assignments page is very useful. Thanks for adding it. Would it be
possible to add an option to restrict the trial factoring to a specified
upper bound?

[QUOTE=Graff;162908]The ability to request exponents in a specified range of the Manual
Assignments page is very useful. Thanks for adding it. Would it be
possible to add an option to restrict the trial factoring to a specified
upper bound?[/QUOTE]

An additional "would be nice" feature request: a unreserve option under
the Manual Testing menu that has a simple text area into which one can type
exponents that are to be unreserved and a submit button. While you can
unreserve exponents using the My Accounts -> Assignments option, the
cgi script that generates that page times out when you have a lot of
assignments. In order to keep my machines busy for a week, I need to
reserve about 12000 exponents and that is too much for the script.

Graff

One Worker of Core Duo Lost assignments....
 

I have a core Duo E6600 with two workers both running LL&DC

Early Feb when the server released all the v4 assignments I grabbed about a 20 28M LL tests for this PC; 10 for each worker; Each worker previously had about 7 18M DC tests and 5 28M LL tests. These assignments would bring each worker up to 240 days.

I have in prime.txt
DaysOfWork=90
UnreserveDays=300

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. However it only got enough work for 90 days; 6 of the same LL assignments returned for a net loss of 9.

Here are the relevant lines from prime.log
[CODE][Tue Feb 17 08:16:31 2009 - ver 25.9]
Unreserving M28650653
Unreserving M28652207
Unreserving M28653631
Unreserving M28655113
Unreserving M28655227
Unreserving M28203107
Unreserving M28216003
Unreserving M28218889
Unreserving M28226197
Unreserving M28244311
Unreserving M28246807
Unreserving M28248397
Unreserving M28252463
Unreserving M28259353
Unreserving M28260691
Got assignment: LL M28203107
Got assignment: LL M28216003
Got assignment: LL M28218889
Got assignment: LL M28226197
Got assignment: LL M28244311
Got assignment: LL M28246807[/CODE]

Anyone else have similar experiences?
Anyone know why this happened?

Ooh, I hate when that happens!
 

[quote=petrw1;163146]I have a core Duo E6600 with two workers both running LL&DC

Early Feb when the server released all the v4 assignments I grabbed about a 20 28M LL tests for this PC; 10 for each worker; Each worker previously had about 7 18M DC tests and 5 28M LL tests. These assignments would bring each worker up to 240 days.

I have in prime.txt
DaysOfWork=90
UnreserveDays=300

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. However it only got enough work for 90 days; 6 of the same LL assignments returned for a net loss of 9.[/quote]

Yeah, this has happened to me before, and is quite annoying when it does happen, as I like to hang on to my exponents (how badly would it suck to lose M47 to someone else?!?) even if I pick them up by mistake. I too have DaysOfWork set to 90 and I go really crazy setting the UnreserveDays to something like 1460 (4 years) or even 3650 (10 years). I also make sure that MaxExponents is set to something high like 999. But I have still had instances where I add exponents to my worktodo file, and communicate with the server, only to have a whole bunch of exponents unreserved seemingly for no reason. It's then nigh impossible to get them all back, especially smaller ones, as the server will immediately hand them out to other people.

Since I've upgraded all of my computers to v25.9.3, I haven't seen this bizarre behavior, thankfully, and I too have stocked up my cores with 36 new assignments - 28 28Ms and 8 31Ms, to go with about 50 other assignments in the mid and high 30s, and newer stuff in the 43 and 46M range (for some reason, I've never been given a 44M or 45M exponent). The upshot of this is that I have 13 cores stacked up with enough work for the next 230 days or so (assuming I don't get lucky with P-1), but staggered nicely so that I see a new LL result roughly every 5 days, which is pretty neat.

[QUOTE=NBtarheel_33;163173]Since I've upgraded all of my computers to v25.9.3, I haven't seen this bizarre behavior, thankfully.[/QUOTE]

At least I know I am not crazy now (well maybe not as crazy anyway).

I would upgrade all to 29.3 except that a few tests have shown that it is slightly SLOWER for a PIV. But actually this Duo (and a Quad) were already upgraded to 25.9 Build 3 when this happened.

I am hoping this is a freak occurence. If on the other hand it is a known (dare I say) bug then there may be documentation on how to avoid it because whereas I will NEVER consider myself more worthy than anyone else in getting preferred assignments I don't like losing those I was fortunate enough to acquire.

[quote]
I would upgrade all to 29.3 except that a few tests have shown that it is slightly SLOWER for a PIV.[/quote]

Is this based on your own testing, or on what you have read here? If it's the latter, you might want to run your own tests - I find build 3 to be slightly faster on the Prescott P4s I have borged - last night I saw iteration times of 79ms for a 46M exponent, and before build 3, I had *never* seen the iteration time crack 80ms. 1ms * 46M = 46000 seconds, which is just under a savings of 1/2 day.

[quote]I am hoping this is a freak occurence. If on the other hand it is a known (dare I say) bug then there may be documentation on how to avoid it because whereas I will NEVER consider myself more worthy than anyone else in getting preferred assignments I don't like losing those I was fortunate enough to acquire.[/quote]

If you have UnreserveDays and MaxExponents set high enough, as I have done, to me this has got to be a bug that George may/may not be aware of. If this is a bug that cannot be easily tracked down and fixed, what might be a good idea is to protect released exponents for some interval after their release (e.g. 15 minutes) so that they are not immediately available to be snatched up. Don't know how hard it would be to implement, but I imagine it could be done by keeping an exponent in "limbo", i.e. registered to a user (and able to be registered under the old hex AID) for say 15 minutes, *even after the unreservation of the exponent in question*.

I agree that this is something that does need to be resolved one way or another, as it is very annoying to be in endless cycles of reserving and unreserving and keeping AIDs straight, especially in my case where I keep a pool of over 80 exponents, half of which would be "preferred".

Prime95 once also randomly unreserved an exponent assigned to me. It too was a "first-time test" (there was one suspect result reported before on that exponent), it was manually reserved.

(on my pentium 4 prescott) assuming v25.9.3 is "p95v259.zip", it's about the same as v25.8.5 which I will continue to use

Great work on v5.0! That said, I can't be the only one a tiny bit disappointed that my account no longer have a track of when I first joined GIMPS some 10 years ago.

"Account created 2008-10-29 19:15 UTC" <-- somehow, there's not the same fun to this