Mersenne.ca Status Report

[blip]

Originally Posted by snme2pm1

Till now, I have refrained from comment during this long outage.
It is sad that a rogue one or several account holders have again issued a torpedo so as to seriously disrupt proceedings at PrimeNet and consequentially mersenne.ca.
A greater level of resilience would be desirable.
It seems despite some slight movement, mostly the statistics are quite stale and unhelpful.
Good if James is enjoying a lovely holiday, which seems likely since he hasn't replied here.

Well, I don't see any serious disruption or anything even remotely close to that, and never saw. I just made the observation, that page again delivers statistics, which is nice and lets me hope, we will have current data again in the near future. As far as I understood, mersenne.ca is an auxiliary server not directly part of primenet, but a close friend of it. So, what risk do you see here for primenet core operations?

[snme2pm1]

Originally Posted by blip

Well, I don't see any serious disruption or anything even remotely close to that, and never saw. I just made the observation, that page again delivers statistics, which is nice and lets me hope, we will have current data again in the near future. As far as I understood, mersenne.ca is an auxiliary server not directly part of primenet, but a close friend of it. So, what risk do you see here for primenet core operations?

So far as I am aware, the mersenne.ca statistics have been largely dysfunction since 2015-11-16 when bogus assignment results were submitted to PrimeNet.
I am aware that mostly, the presentation of statistics faltered with an error message in recent days.
I am also aware that results presented by mersenne.ca. for example, earlier today claiming to be most recent, were instead several days old.

[ramgeis]

Actually it says that the most recent data is from 24 Nov 2015 but does not claim the data to be most recent.
Unfortunately the data for that date is not in sync either. I assume it is still missing the updates from the days with the bogus results.
Nevertheless it is already helpful that the status page is up again as a rough overview is better than no overview at all.

[lycorn]

Absolutely. That means things are "moving again".
But in fact there are still malfunctions to correct: e.g. try to get comparison of dates. You´ll find funny things like the Unfactored exponents largely outnumbering those Factored.

[Madpoo]

Originally Posted by lycorn

Absolutely. That means things are "moving again".
But in fact there are still malfunctions to correct: e.g. try to get comparison of dates. You´ll find funny things like the Unfactored exponents largely outnumbering those Factored.

I'm sure once James is back in the saddle (I presume he's vacationing, but that's a guess), he'll get it straightened out on his side.

The bogus results that mucked it up: since that was the second time it messed up the daily XML dump of logs that he uses, I should probably do something about that. At the very least I could put something in there so it just ignores any result from that day with a GHz_Days value that is obviously wrong (and overflows the XML generation script... can't remember why but I think I'm casting the "float" value to something else, or rounding it in some way maybe, I'm not sure why it choked on those crazy values).

The one thing I won't bother fixing is displaying "factored to bits" higher than 99 on the web "exponent report" page. It assumes it'll be 2 digits so 2^777 showed up as 2^77. It's a display only issue and it's because I used some SQL shortcuts to parse that part out of the result text, and fixing it seemed like work. I can't imagine we'll *actually* trial factor anything beyond 99 bits anytime soon. If we get to that point, I'd be happy to correct it then. LOL

EDIT: Looking at my daily XML generation script... I'm casting the float value for GHz_Days to NUMERIC(10,4) to round it to 4 sig digits. Which of course barfs when the FLOAT value itself is super crazy big. I'll just exclude any results with impossibly large numbers which will "solve" this and also prevent feeding funky data to James' system in the first place.

If anyone is curious, the record for the most GHz_Days given for a single result is:
M1217 completed 250000 ECM curves, B1=10000000, B2=1000000000000

That earned 277238.39321597 GHz Days.

In fact, the user that submitted that (Never Odd Or Even) has the top 19 largest GHz-Days results. Also, of the top 20, 19 are ECM efforts and #20 is a TF to 82 bits for M9007753 (by dbaugh, who has declared that exponent his nemesis for defying his early LL test effort... topic was covered in another thread recently).

It may be odd that he's spent so much time and resources to find *additional* factors for M1217 considering 3 factors are known, but hey, do what you enjoy.

Anyway, given these stats, I think it would be safe to say we wouldn't expect to see a single result come in that exceeded 300,000 GHz Days? Someone obviously could decide to run hundreds of thousands of ECM curves on something in one big chunk, but I think it's more typical to do smaller # of curves in an assignment, not 250,000 at once like M1217 got.

I'll pick a "safe" # to exclude results higher than. And this would only be for the daily XML report generation... the server itself would still potentially accept a funky result which is fine since we can weed out the goofballs after the fact.

[chalsall]

Originally Posted by Madpoo

If anyone is curious, the record for the most GHz_Days given for a single result is:
M1217 completed 250000 ECM curves, B1=10000000, B2=1000000000000

Just to put on the table as a question, is ECM normalized to TF, P-1 or LL (or DC)?

I personally don't care, except when it breaks the statistics.

[LaurV]

Originally Posted by Madpoo

If anyone is curious, the record for the most GHz_Days given for a single result is:
M1217 completed 250000 ECM curves, B1=10000000, B2=1000000000000
That earned 277238.39321597 GHz Days.

In fact, the user that submitted that (Never Odd Or Even) has the top 19 largest GHz-Days results. Also, of the top 20, 19 are ECM efforts and #20 is a TF to 82 bits for M9007753 (by dbaugh, who has declared that exponent his nemesis for defying his early LL test effort... topic was covered in another thread recently).

It may be odd that he's spent so much time and resources to find *additional* factors for M1217 considering 3 factors are known, but hey, do what you enjoy.

I repeatedly "complained" about NOOE, but George said in the past that he is trusting that user. He might have a reason, like knowing him personally or so (I assume). He used to communicate directly with George, who backed him. I "was convinced" that his "highest ever" LL was bogus (due to form of exponent and reporting times, with 38 minutes and 83 seconds or so), but your own TC later proved the result legit .

I still believe all (or part of) his "big results" for ECM are bogus, he jumped in a very short time to the top of the top in ECM and stayed there, over people who "dedicated their life" to ECM factoring. OTOH, these exponents can be done on the GPU, so it may be that he really invested big computing resources and some time resources, into it. You may check with George if these big results are not manually added by George himself.

Till proved wrong, I still believe he didn't do any ECM for this exponent, possible that he only "took the cream" and reported the huge qty of ECM done by the Cunningham project. Or he just considered that information, and decided to get some GHzDays of credit, based on the fact that 'the task was done, anyhow', so it is not a "false information" added to the data base. I mean, I don't contest the number of curves, this exponent had even more ECM done, inside of the Cunningham project. I only contest the fact that NOOE did it by himself.

[snme2pm1]

Originally Posted by Madpoo

The bogus results that mucked it up: since that was the second time it messed up the daily XML dump of logs that he uses, I should probably do something about that. At the very least I could put something in there so it just ignores any result from that day with a GHz_Days value that is obviously wrong ...
I'll just exclude any results with impossibly large numbers which will "solve" this and also prevent feeding funky data to James' system in the first place ....
I'll pick a "safe" # to exclude results higher than. And this would only be for the daily XML report generation... the server itself would still potentially accept a funky result which is fine since we can weed out the goofballs after the fact.

Would it be feasible to introduce (or hopefully strengthen) result income side vetting so as to raise an exception alert when various criteria are met.
Various parameters might be in play apart from merely the credit.
That alert could trigger a message to interested parties indicating that a submitted result deserves scrutiny.
I have an awkward feeling about trying to pick an arbitrary number for credit alone so as to cause deletion of data at a later migration stage.

[Prime95]

Originally Posted by LaurV

I still believe all (or part of) his "big results" for ECM are bogus, he jumped in a very short time to the top of the top in ECM and stayed there, over people who "dedicated their life" to ECM factoring. OTOH, these exponents can be done on the GPU, so it may be that he really invested big computing resources and some time resources, into it. You may check with George if these big results are not manually added by George himself.

It is easy to get "inflated" ECM credit by using GMP-ECM -- especially for small exponents. If you look at the example madpoo quoted, B2 = 10000 * B1 instead of the more normal 100 * B1. The server calculates CPU credit assuming prime95's poor stage 2 algorithm instead of GMP-ECM's superior stage 2 algorithm.

In a way this is similar to people using mfaktc climb the charts with tons of TF credit. The overall top producers page is inaccurately comparing apples (prime95 users) to oranges (GPU TFers) to lemons (GMP-ECM users).

[kladner]

Originally Posted by Prime95

It is easy to get "inflated" ECM credit by using GMP-ECM -- especially for small exponents. If you look at the example madpoo quoted, B2 = 10000 * B1 instead of the more normal 100 * B1. The server calculates CPU credit assuming prime95's poor stage 2 algorithm instead of GMP-ECM's superior stage 2 algorithm.

In a way this is similar to people using mfaktc climb the charts with tons of TF credit. The overall top producers page is inaccurately comparing apples (prime95 users) to oranges (GPU TFers) to lemons (GMP-ECM users).

I can't address the comparisons between types of work directly, but I would offer that almost any procedure can be misused to game the system. I don't know if I 'deserve' the credits I get for LLTF, but I am helping the effort to keep TF out in front of LL needs, and those GPUs do drink the 'electric fluid' freely, and turn out lots of cycles. I guess that could be taken as an argument that credit is an incentive to invest the hardware and the power to turn out those cycles.

I only took up factoring when I got a GTX GPU, so I can't relate to doing it on a CPU. I wonder how the cycles-per-watt would work out doing a similar amount of TF on a recent Xeon system, as well as the time required. Still, I pay my CPU dues with 75% DC, 25% LL, on a not-very-efficient-or-terribly-productive CPU.

I don't care that much if someone runs up large, possibly bogus numbers. I run a single, stock (AMD FX) system, with two (overclocked) 580 GPUs. I mostly look at GPU72 graphs for standing, but I am not disappointed when I look at PrimeNet statistics, either. Like LaurV, I do have to admit to being a credit whore, but I try to come by credit while contributing to the purpose of the project.

Sorry for what might seem like a rant. I'm probably just expelling guilt over my power usage.

[VictordeHolland]

Originally Posted by Prime95

The server calculates CPU credit assuming prime95's poor stage 2 algorithm instead of GMP-ECM's superior stage 2 algorithm.

Maybe GMP-ECM credit could be given for CPUtime instead of the inflated results. But then all the previous results would have to be changed to be fair. On the other hand, a bit extra credit for the extra trouble might persuade people to use the more efficient GMP-ECM stage 2 on small exponents.

In a way this is similar to people using mfaktc climb the charts with tons of TF credit. The overall top producers page is inaccurately comparing apples (prime95 users) to oranges (GPU TFers) to lemons (GMP-ECM users).

Yep, and that is inevitable with developments in software and hardware. Changing it now will only have an effect for a few years until the next super LL-card or AVX5.0 comes along.