mersenneforum.org LMH status
 Register FAQ Search Today's Posts Mark Forums Read

2009-11-03, 20:37   #276
Uncwilly
6809 > 6502

"""""""""""""""""""
Aug 2003
101×103 Posts

100101000010102 Posts

Quote:
 Originally Posted by chalsall What one sees over on wabbit.com is an abstract of the database kept on another one of my servers, which is itself a dataset periodically updated by the occasional spidering of PrimeNet (and a great deal of PERL), and the work that my own swarm of "workers" does. I don't want to put too much load on PrimeNet, so I only update every few days. I have, however, figured out a way to keep my dataset no more than 24 hours out of date, while minimizing the queries to PrimeNet.
Quote:
 Originally Posted by petrw1 It is at least several days old. I was working on TF 80M to 64 bits. It still shows 98 in the 80.3M range. There were 98 about a week ago and the last one finished yesterday.
This is from the rabbit's mouth.

2009-11-03, 21:09   #277
petrw1
1976 Toyota Corona years forever!

"Wayne"
Nov 2006

23×52×23 Posts

Quote:
 Originally Posted by chalsall What one sees over on wabbit.com is an abstract of the database kept on another one of my servers, which is itself a dataset periodically updated by the occasional spidering of PrimeNet (and a great deal of PERL), and the work that my own swarm of "workers" does. I don't want to put too much load on PrimeNet, so I only update every few days. I have, however, figured out a way to keep my dataset no more than 24 hours out of date, while minimizing the queries to PrimeNet.
Just a thought: If the Progress Report / Recent Results report that runs hourly had a complete hour of results you would only need to query ("spider") the current factoring results once and use these hourly Results to keep it current. But as it is, there could be as little as a few minutes of results if someone happens to report in a whole bunch of manual results.

2009-11-04, 16:15   #278
chalsall
If I May

"Chris Halsall"
Sep 2002

7·1,361 Posts

Quote:
 Originally Posted by petrw1 Just a thought: If the Progress Report / Recent Results report that runs hourly had a complete hour of results you would only need to query ("spider") the current factoring results once and use these hourly Results to keep it current. But as it is, there could be as little as a few minutes of results if someone happens to report in a whole bunch of manual results.
That's sort of what I do... I compare the summary page from what my spider previously saw, and then only spider those million blocks which have changed.

My apologies to everyone for the dataset not being updated as regularly as I have been doing in the past. I have been heavily involved as an Intervenor during a Rate Review Hearing for the last month. When not in court, I've been studying 1400 pages of evidence preparing for my cross examination of the electrical company's witnesses.

I have just updated the dataset to Nov 1, and am currently running the spider for today. I'm now comfortable enough with the stability of the spider that I can cronjob it without worry it will do something stupid, so the results will be updated daily.

Also, I've been doing some other minor work on the tool, including moving it to a dedicated domain. Please see http://www.mersenne.info/trialfactored.cgi Amongst other things, the bars have been made smaller, causing less obstruction of bars behind.

As always, feedback welcome.

Last fiddled with by chalsall on 2009-11-04 at 16:15 Reason: s/then then/and then/

 2009-11-06, 16:14 #279 petrw1 1976 Toyota Corona years forever!     "Wayne" Nov 2006 Saskatchewan, Canada 23·52·23 Posts High level factoring summary chart.... This was done manually but would not have been possible without the chalsall graphs. - Each row represents one 100 million range. - Each digit represents the LOWEST 6x bit level to which EVERY exponent in that million range has been factored to at least that many bits. - Where you see a dash it means less than 60 bits; which in every case is 59 bits except for a few under 20,000 which are 58 bits. - For example the lone 6 amidst the sea of 4's in the 300: row means that ALL exponents in the 333,xxx,xxx range are factored to at least 66 bits. - Currently TF-LMH is assigning exponents that are under 60 bits (dashed). At the current rate of completion they will run out in 2010. Code: ---- ----0----- ----1----- ----2----- ----3----- ----4----- ----5----- ----6----- ----7----- ----8----- ----9----- 000: -011123334 4444555566 6677777776 7777767766 6688888666 4444447444 4444444444 4444444444 4433444444 4444444444 100: 3333333333 3333333333 3333333333 3333333333 3333333333 3333333333 3333333333 3333333333 3333333333 3333333333 200: 3111111111 2222222222 1131111111 1111111111 1111111111 1111111111 1111111111 1111111111 1111111111 1113111111 300: 3333333333 4444444444 4444444444 4464444444 4444444444 4444444444 4444444444 4444444444 4444444444 4444444444 400: 1111113111 1111111111 1111111131 1111111111 1111111111 1111111111 1111111111 1111111111 1111111111 1111111112 500: 3333333333 2222222222 2222222222 2222222222 2222222222 4444444444 3333333333 2222222222 1111111111 0000000000 600: ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- 700: 33333----3 ---------3 -------333 3333333333 3333333333 3333333333 3333333333 3333333333 3333333333 111----3-- 800: 33-------- ---------- --333----- ---------- 00000000-0 000-0----- ---------- ---------- ---------- ---------- 900: ---------- ---------- ---------- ---------- ---------- 3--------- ----3----- ---------- -------3-- -----33333
2009-11-06, 19:21   #280
chalsall
If I May

"Chris Halsall"
Sep 2002

952710 Posts

Quote:
 Originally Posted by petrw1 This was done manually but would not have been possible without the chalsall graphs.
Thank you. A worthwhile query.

I have codified this into Perl, and have added a Maximum and Average value into a graph. This is now live from my database. (While I enjoy legal proceedings, my first love is software.)

Attached Thumbnails

 2009-11-06, 21:32 #281 garo     Aug 2002 Termonfeckin, IE 32×307 Posts 987M is done to 64 bits. I did it but petrw1's table shows 3! Interesting how the two different representations complement each other and provide somewhat different information.
2009-11-06, 22:54   #282
chalsall
If I May

"Chris Halsall"
Sep 2002

253716 Posts

Quote:
 Originally Posted by garo 987M is done to 64 bits. I did it but petrw1's table shows 3! Interesting how the two different representations complement each other and provide somewhat different information.
That will be a function of temporal sampling.

Indeed, 987M is at 64 bits... http://www.mersenne.info/trialfactor...000000,1000000
Attached Thumbnails

2009-11-06, 23:20   #283
petrw1
1976 Toyota Corona years forever!

"Wayne"
Nov 2006

23×52×23 Posts

Quote:
 Originally Posted by chalsall Indeed, 987M is at 64 bits...

 2009-11-27, 21:11 #284 petrw1 1976 Toyota Corona years forever!     "Wayne" Nov 2006 Saskatchewan, Canada 23×52×23 Posts <60 bit Progress!!!!!! WOW...my rough counting from the graphs indicates that the number of exponents factored to less than 60 bits dropped from about 3.8M to about 1.8M in the last ONE week ... over 50%. + On the plus side is the obvious progess to LMH and GIMPS overall by eliminating exponents. + Another plus is that as we get into higher level factoring assignments that take longer to compete the database/server traffic will decrease. - I could suggest that a negative is that once the <64 TF bit assignments are gone the 32 bit architecture machines lose the one type of work they are the most efficient at. I have one left; I just retired one 3 days ago. Last fiddled with by petrw1 on 2009-11-27 at 21:12
2009-11-27, 23:20   #285
chalsall
If I May

"Chris Halsall"
Sep 2002

7·1,361 Posts

Quote:
 Originally Posted by petrw1 WOW...my rough counting from the graphs indicates that the number of exponents factored to less than 60 bits dropped from about 3.8M to about 1.8M in the last ONE week ... over 50%.
Yeah. My cluster is currently working in the 900M range, bringing anything not being worked by others up to 63.
Code:
+------------+------------+-------------+---------+
| RangeStart | RangeDepth | FactorDepth | FDCount |
+------------+------------+-------------+---------+
|          0 |  100000000 |          59 |       7 |
|  600000000 |  100000000 |          59 | 1227914 |
|  700000000 |  100000000 |          59 |  392112 |
|  900000000 |  100000000 |          59 |  104330 |
+------------+------------+-------------+---------+

2009-12-03, 22:57   #286
petrw1
1976 Toyota Corona years forever!

"Wayne"
Nov 2006

23·52·23 Posts

Quote:
 Originally Posted by chalsall Yeah. My cluster is currently working in the 900M range, bringing anything not being worked by others up to 63.
Just a suggestion but while you are doing this; if you set your factoring limits to go to 63 bits immediately (i.e. FACTOR=900000001,59,63) you will significantly reduce server traffic when reporting results. Only one result would be sent per assignment and even a slow PIV would complete it in minutes.

Last fiddled with by petrw1 on 2009-12-03 at 22:58

 Similar Threads Thread Thread Starter Forum Replies Last Post Primeinator Operation Billion Digits 5 2011-12-06 02:35 1997rj7 Lone Mersenne Hunters 27 2008-09-29 13:52 Uncwilly Operation Billion Digits 22 2005-10-25 14:05 paulunderwood 3*2^n-1 Search 2 2005-03-13 17:03 1997rj7 Lone Mersenne Hunters 25 2004-06-18 16:46

All times are UTC. The time now is 13:27.

Thu Apr 15 13:27:52 UTC 2021 up 7 days, 8:08, 0 users, load averages: 2.43, 2.56, 2.29