LMH status

[Uncwilly]

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.

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.

[petrw1]

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.

[chalsall]

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.

[petrw1]

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.

---- ----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

[chalsall]

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.)

Please see http://www.mersenne.info/tfminmax.cgi

[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.

[chalsall]

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

[petrw1]

Originally Posted by chalsall

Indeed, 987M is at 64 bits...

Me bad

[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%.

+ 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.

[chalsall]

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.

+------------+------------+-------------+---------+
| RangeStart | RangeDepth | FactorDepth | FDCount |
+------------+------------+-------------+---------+
|          0 |  100000000 |          59 |       7 | 
|  600000000 |  100000000 |          59 | 1227914 | 
|  700000000 |  100000000 |          59 |  392112 | 
|  900000000 |  100000000 |          59 |  104330 | 
+------------+------------+-------------+---------+

[petrw1]

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.