mersenneforum.org > Data Mersenne.ca Status Report
 Register FAQ Search Today's Posts Mark Forums Read

2015-11-28, 17:38   #23
Serpentine Vermin Jar

Jul 2014

22·3·277 Posts

Quote:
 Originally Posted by Prime95 It is easy to get "inflated" ECM credit by using GMP-ECM -- especially for small exponents.
In the case of M1217 and the ECM results from NOoE, the messages have what I think are the checksums (no assigmnent ID though, but that's not unusual).

The weird thing is, a lot of his results have the *same* 64-bit checksum value even though the message itself is different (diff # of curves or bounds). Some are the same message (same curves/bounds/checksum) which, again, isn't unusual for ECM since people can and do run the same # of curves and bounds on parallel threads.

But then, how do we know he really ran 17 x 91 curves, or just did that one time and submitted 17 times?

Also, the app ID indicated in the result says it came from: "Windows64 Prime95 v26"

250,000 curves with those bounds would have taken quite a bit of time, and for all I know he really did it: I have no opinion.

2015-11-28, 20:28   #24
bloodIce

Feb 2010
Sweden

2558 Posts

Quote:
 But then, how do we know he really ran 17 x 91 curves, or just did that one time and submitted 17 times?
There are several ways of submitting reports, which will look legit, but are not (and you and George know them all + some extra). This particular user is also on my watch for several years and I will not be amazed if something is fishy. However, we cannot blame someone without evidence of wrongdoing, so by definition s(he) is innocent. There are two ways to contra-act the problem. Firstly factor completely 1217 (), but more seriously why not implement a ECM/Pm1/TF checksums dependent on the data/time of the completion start of a task in any further versions of prime95.

Last fiddled with by bloodIce on 2015-11-28 at 20:33

2015-11-28, 22:33   #25
Gordon

Nov 2008

3·167 Posts

Quote:
 Originally Posted by bloodIce There are several ways of submitting reports, which will look legit, but are not (and you and George know them all + some extra). This particular user is also on my watch for several years and I will not be amazed if something is fishy. However, we cannot blame someone without evidence of wrongdoing, so by definition s(he) is innocent. There are two ways to contra-act the problem. Firstly factor completely 1217 (), but more seriously why not implement a ECM/Pm1/TF checksums dependent on the data/time of the completion start of a task in any further versions of prime95.
Because there are quite a few of us who do Stage 1 in P95 and stage 2 in gmp-ecm, no check-sums to check-in!

2015-12-02, 23:54   #26
Gordon

Nov 2008

3·167 Posts

Quote:
 Originally Posted by Madpoo In the case of M1217 and the ECM results from NOoE, the messages have what I think are the checksums (no assigmnent ID though, but that's not unusual). The weird thing is, a lot of his results have the *same* 64-bit checksum value even though the message itself is different (diff # of curves or bounds). Some are the same message (same curves/bounds/checksum) which, again, isn't unusual for ECM since people can and do run the same # of curves and bounds on parallel threads. But then, how do we know he really ran 17 x 91 curves, or just did that one time and submitted 17 times? Also, the app ID indicated in the result says it came from: "Windows64 Prime95 v26" 250,000 curves with those bounds would have taken quite a bit of time, and for all I know he really did it: I have no opinion.
Is perchance the checksum - Wd9: 00000000

2015-12-03, 03:26   #27
Serpentine Vermin Jar

Jul 2014

332410 Posts

Quote:
 Originally Posted by Gordon Is perchance the checksum - Wd9: 00000000
LOL... nope. I would have noticed that.

 2015-12-24, 07:32 #28 Dubslow Basketry That Evening!     "Bunslow the Bold" Jun 2011 40
 2016-01-26, 08:11 #29 lycorn     "GIMFS" Sep 2002 Oeiras, Portugal 27648 Posts Prime count not yet updated in the reports http://www.mersenne.ca/status/tf/0/0/1/0
2016-02-10, 05:41   #30
snme2pm1

"Graham uses ISO 8601"
Mar 2014
AU, Sydney

5×53 Posts

Quote:
 Originally Posted by Gordon It seems that the status report han't been updated since 16th, can someone restart the script process...
Seems to be another pause in progress, now we're at UTC 2016-02-10 yet response from such as above reflect 2016-02-07.
It seems odd that mersenne.ca contents list doesn't include such (not quite so) new facilities, such that a person can encounter them without learning a link from mersenneforum.org.

2016-02-11, 13:14   #31
James Heinrich

"James Heinrich"
May 2004
ex-Northern Ontario

E1116 Posts

Hmm, seems this thread is about mersenne.ca but I wasn't subscribed to it so I didn't know there was stuff going on. Thanks snme2pm1 for bringing my attention to it.

Quote:
 Originally Posted by Dubslow Does anyone know if and where I might find the mersenne.ca equivalent of http://www.mersenne.info/exponent_st...ine_graph/1/0/ ?
That would be here: http://www.mersenne.ca/status/ll/0/0/2/0

Quote:
 Originally Posted by lycorn Prime count not yet updated in the reports
Thanks, fixed.

Quote:
 Originally Posted by snme2pm1 Seems to be another pause in progress, now we're at UTC 2016-02-10 yet response from such as above reflect 2016-02-07. It seems odd that mersenne.ca contents list doesn't include such (not quite so) new facilities, such that a person can encounter them without learning a link from mersenneforum.org.
I changed the database structure on 2016-02-08 and that actually went fine, but one small unrelated typo at the same time broke the daily jobs, so they didn't run for the last 3 days. I have spent the last hour or so rebuilding that data so it should be working as expected now. I also added a link to visualization from the menu (and changed the big graph link on the home page to point to visualization rather than graphs).

Last fiddled with by James Heinrich on 2016-02-11 at 13:19

 2016-02-12, 02:26 #32 LaurV Romulan Interpreter     "name field" Jun 2011 Thailand 71×139 Posts Nice! Thanks! BTW I think you should start to collect clLucas results in that table of cudaLucas fire power. By the same logic as the sister-table of mfaktX results contains both AMD and Nvidia boulders, now after msft's last additions, clLucas became quite competitive, at least (or "not only"?) for some ranges where power of 2 fft's are adequate (I would argue about "not only", thinking about the prices for new amd cards, but that is a different discussion). The idea is that the table of xxLucas could contain AMD results too. What do you think? Last fiddled with by LaurV on 2016-02-12 at 02:27
 2016-02-12, 05:39 #33 LaurV Romulan Interpreter     "name field" Jun 2011 Thailand 71·139 Posts [time limit] It occurred to me that the prices in the tables have to be updated too. Especially for a K80, you could buy it now for $3800 (one used at$3900 and 13 new at $4100 on Amazon, just for example, the first popup when search by google). Therefore lowering the price from$5k on the table will really improve their "james' value ratio" (don't laugh, that is a very good indicator! ), making it highly comparable with the Titans, especially as we switch to higher and higher exponents, more memory (and especially ECC memory!) for larger FFTs becomes a must (and it should also count toward the score, but that is a different story). One can not anymore use the cheaper version of the gtx580 (the one with 1.5GB memory only) to run the higher FFTs required for a LMH exponent, at least 2-3GB is a must, therefore that will soon be only the niche of Titans and Teslas (or the elite versions of gtx 5/6/780 or 90 with 3GB of RAM) [edit, or other newer thingies yet to come, not forgetting AMD cards as clLucas got faster now] Last fiddled with by LaurV on 2016-02-12 at 05:45

 Similar Threads Thread Thread Starter Forum Replies Last Post Gordon mersenne.ca 21 2019-01-21 02:38 Dubslow PrimeNet 2 2015-10-05 05:21 Gordon mersenne.ca 1 2015-09-22 10:53 rogue Sierpinski/Riesel Base 5 8 2006-03-04 13:59 PrimeCruncher PrimeNet 11 2005-10-09 18:53

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

Sun Jan 23 00:13:57 UTC 2022 up 183 days, 18:42, 0 users, load averages: 2.13, 1.94, 1.54