![]() |
![]() |
#628 |
Feb 2012
40510 Posts |
![]()
aurashift, your usslcburnin57 reports as anonymous user. You may want to check that out.
|
![]() |
![]() |
![]() |
#629 |
Aug 2010
Republic of Belarus
2·89 Posts |
![]()
Intresting thing.
For last exponent that already tested by aurashift: Code:
2016-05-22 aurashift C 70BD2A34463E69__ 2016-03-19 aurashift NF no factor from 2^76 to 2^77 2016-03-08 aurashift NF-PM1 B1=3165000, B2=104445000, E=12 2015-02-05 Jacques MOLNE NF no factor from 2^75 to 2^76 2015-02-02 Jacques MOLNE NF no factor from 2^74 to 2^75 2015-01-28 Xebecer NF no factor from 2^73 to 2^74 2013-01-25 LaurV NF no factor from 2^72 to 2^73 2011-06-12 rduerr NF no factor from 2^68 to 2^71 2010-04-03 Team_Inspector NF no factor from 2^67 to 2^68 I checked this diapason and didn't find factor ... But why it possible and Prime95 starting LL test. And finally ... When i tried to upload reuslt it said me: Code:
Found 1 lines to process. processing: TF no-factor for M332402051 (2^71-2^72) Error code: 40, error text: TF result for M332402051 was not needed Could someone explain it? ![]() http://www.mersenne.org/report_expon...2402051&full=1 |
![]() |
![]() |
![]() |
#630 |
"James Heinrich"
May 2004
ex-Northern Ontario
32×5×7×13 Posts |
![]()
Actually, it wasn't skipped.
I think it's a side effect of how the results log is displayed on mersenne.org when two results exist with identical timestamps. In this example, LaurV submitted both 71-72, and 72-73, at the same timestamp of 2013-01-25T06:47:00. You can see this on the mersenne.ca page for M332402051. |
![]() |
![]() |
![]() |
#631 |
Aug 2010
Republic of Belarus
2·89 Posts |
![]()
Ahhh, yes. Anyway it looks like bug on mersenne.org that should be fixed.
![]() |
![]() |
![]() |
![]() |
#632 |
Romulan Interpreter
"name field"
Jun 2011
Thailand
101000001010012 Posts |
![]()
Ha! Was it me again?!
![]() This is side effect of Misfit reporting the results in buckets, every hour or so, and not when they are found (which is good, otherwise we would need to connect to the server every few seconds, to send a couple of bytes). Now, I think the problem should be easily fixed (temporarily) by you or Madpoo, just query the db for results with same time stamp [edit: for the same exponent], and move one or the other few seconds up or down. In the future, this phenomenon will be rarer and rarer as we progress to higher bitlevels, so a "firmware" fix is not very imperative. If you remember, in the past I suspected this might be the case for some exponents from the "skipped bitlevels" project, the work was done, but not shown in the DB, and we did it again. [edit: the work for bitlevel 58 or so, we did it triple times actually, considering Tjaoi's work] Last fiddled with by LaurV on 2016-05-23 at 02:09 |
![]() |
![]() |
![]() |
#633 |
Jan 2015
111111012 Posts |
![]() |
![]() |
![]() |
![]() |
#634 |
Jan 2015
11×23 Posts |
![]() |
![]() |
![]() |
![]() |
#635 |
"David"
Jul 2015
Ohio
20516 Posts |
![]()
I did some hardware testing for further contributions to the 100M range:
108 days for a 100M test on a Fury X. ($629, 200/220W during test - 518.4kWh , $52/test in power - $115/test over three years) vs. 82 days on a GTX1080-FE ($699, 110/180W during test - 216.48kWh, $22/test in power - $75/test over three years) vs. 55 days on a TitanBlack (~$500 used, 247/250W during test - 326kWh, $33/test in power - $58/test over three years) vs. 52 days on an E5-2698v3 16-core Xeon with Quad-Channel DDR4. ($5000+, 110W during test - 137.28kWh, $13/test in power - $251/test over three years) That Xeon has a result due in 13 hours :) Those new GPUs are starting to look tempting though.... Last fiddled with by airsquirrels on 2016-06-12 at 22:31 |
![]() |
![]() |
![]() |
#637 | |
"David"
Jul 2015
Ohio
10058 Posts |
![]() Quote:
Code:
| Jun 12 19:26:44 | M57885161 10000 0x76c27556683cd84d | 3136K 0.19141 2.7796 27.79s | 1:20:41:15 0.01% | | Jun 12 19:27:13 | M57885161 20000 0xfd8e311d20ffe6ab | 3136K 0.18750 2.8876 28.87s | 1:21:32:50 0.03% | | Jun 12 19:27:43 | M57885161 30000 0xce0d85ab0065a232 | 3136K 0.18750 3.0057 30.05s | 1:22:27:41 0.05% | | Jun 12 19:28:14 | M57885161 40000 0x6746379dfc966410 | 3136K 0.17969 3.0245 30.24s | 1:22:59:22 0.06% | | Jun 12 19:28:44 | M57885161 50000 0xa5797ceaebc59091 | 3136K 0.17773 3.0120 30.12s | 1:23:15:46 0.08% | Using threads: square 256, splice 128. Starting M74207281 fft length = 4096K | Date Time | Test Num Iter Residue | FFT Error ms/It Time | ETA Done | | Jun 12 19:31:06 | M74207281 10000 0xaa08c91f2f626775 | 4096K 0.10938 3.4714 34.71s | 2:23:32:52 0.01% | | Jun 12 19:31:43 | M74207281 20000 0xa216434787875d0f | 4096K 0.10938 3.6575 36.57s | 3:01:27:21 0.02% | | Jun 12 19:32:21 | M74207281 30000 0x35b1ad9d5eba82cb | 4096K 0.10938 3.7899 37.89s | 3:02:59:40 0.04% | | Jun 12 19:32:58 | M74207281 40000 0x7c7f3019c13f21ca | 4096K 0.11719 3.7631 37.63s | 3:03:37:12 0.05% | Last fiddled with by airsquirrels on 2016-06-12 at 23:30 |
|
![]() |
![]() |
![]() |
#638 |
6809 > 6502
"""""""""""""""""""
Aug 2003
101×103 Posts
3×3,631 Posts |
![]()
Here is the status report for the range from 332192831 to 332399999 (plus other data out to 332999999):
Code:
Date of data 2016/06/20 Average bit depth for first 100 expos 79.22 Average bit depth for first 1000 expos 78.66 Average bit depth for first 5000 expos 76.74 Average bit depth for first 10000 expos 75.94 100th active expo (no factor found) 332198443 1000th active expo (no factor found) 332247691 5000th active expo (no factor found) 332451953 10000th active expo (no factor found) 332701157 Unitless total effort number 552,321,024 Number of first 100 expos to 2^79 100 Number of first 1000 expos to 2^78 882 Number of first 5000 expos to 2^77 2163 Number of first 10000 expos to 2^76 4329 Number left in (classic) range 3988 (The range from 332192831 to 332399999 has less than 4000 left, the range to 332599999 has less than 8000 left, and the range to 332999999 has less than 16000 left.) Estimated expos in range to be removed 102 (by taking all expos to 2^79) Estimated expos in range to be removed 240 (by taking all expos to 2^82) Code:
Bit # at bit level 75 505 76 1395 77 722 78 383 79 771 80 115 81 92 82 2 83 1 84 0 85 2 P-1 731 In rummaging around my HD last night I ran across an early 100M Digit Prefactor Project status graph. The file date is 2004-09-08. That is on the left. On the right is a current graph that covers more than that range. Note the scales on both. |
![]() |
![]() |
![]() |
Thread Tools | |
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
GPU72 / MISFIT use for 100M digit range? | Uncwilly | GPU to 72 | 64 | 2013-03-31 02:45 |
I want a 100M digit Mersenne that.... | JuanTutors | PrimeNet | 8 | 2012-12-06 13:47 |
How far along are you in your 100M digit LL test? | JuanTutors | Lounge | 6 | 2012-02-21 07:36 |
100M-digit n/k pairs | __HRB__ | Riesel Prime Search | 0 | 2010-05-22 01:17 |
100M digit prime | Unregistered | Information & Answers | 10 | 2010-03-24 20:16 |