Announcement: New server coming online (estimated 2017-08-11)

[GP2]

Originally Posted by monst

What's up with M41468027?
One of my machines just submitted results for M41468027.

From this... https://www.mersenne.org/report_expo...exp_hi=&full=1

My "Result" matches the masked result submitted in May, 2008. However the "Residue" reported at that time is different. When I resubmitted the result, the server returned an error that the residue cannot be 0.

Your result doesn't appear in the list of LL test results returned on 2017-08-12, yet it does appear in Recent Cleared. Definitely something odd.

[GP2]

Originally Posted by GP2

Your result doesn't appear in the list of LL test results returned on 2017-08-12, yet it does appear in Recent Cleared. Definitely something odd.

Another question is, why was the 2008-05-10 result from Anonymous only recorded in the History, but never made it into the database. It also seems odd that the 2008-05-11 result, from a different username and with a different residue, occurred so close in time to the Anonymous result; however, see below.

This isn't related to the new server, as far as I can see. The 2008-05-10 result from Anonymous wasn't in a 2016 copy of the database either.

Actually, there's something odd about the May 2008 results: of all the results dated 2008-05 in the database, the vastly overwhelming majority have timestamps with just three dates: 2008-05-10, 2008-05-11, 2008-05-22. Less than a hundred out of eight thousand or so have different dates within that month. Similar disparities occur in other months of 2008 until towards the final months of the year, when the daily amounts are more or less evenly distributed.

Was Primenet working properly during that time? It seems like the database was being updated in large batches, something like that.

[Madpoo]

Originally Posted by GP2

Another question is, why was the 2008-05-10 result from Anonymous only recorded in the History, but never made it into the database. It also seems odd that the 2008-05-11 result, from a different username and with a different residue, occurred so close in time to the Anonymous result; however, see below.

This isn't related to the new server, as far as I can see. The 2008-05-10 result from Anonymous wasn't in a 2016 copy of the database either.

Actually, there's something odd about the May 2008 results: of all the results dated 2008-05 in the database, the vastly overwhelming majority have timestamps with just three dates: 2008-05-10, 2008-05-11, 2008-05-22. Less than a hundred out of eight thousand or so have different dates within that month. Similar disparities occur in other months of 2008 until towards the final months of the year, when the daily amounts are more or less evenly distributed.

Was Primenet working properly during that time? It seems like the database was being updated in large batches, something like that.

Not all older historical entries show up (stuff before 2008 on the old "v4" version of Primenet). I checked on the now-old server and it's not there either so it wasn't something that happened with the move.

As for why the new result got logged okay but didn't make it into the actual LL results, that's odd. I did a quick check of all LL results turned in since the new server went online and that's the only one that happened to.

I'd suggest resubmitting that result manually and see if that does it. If you run into a problem just let me know here and I'll check it out further.

I've submitted a few results manually since the new server went online and they all did okay so I'm pretty sure it's working, just not sure why yours had a problem.

[snme2pm1]

Please amuse us with some statistics regarding the replacement beast.
Memory, CPU, PCIe lanes.
How many spinners and in what configuration?

[Madpoo]

Originally Posted by Madpoo

Not all older historical entries show up (stuff before 2008 on the old "v4" version of Primenet). I checked on the now-old server and it's not there either so it wasn't something that happened with the move.

As for why the new result got logged okay but didn't make it into the actual LL results, that's odd. I did a quick check of all LL results turned in since the new server went online and that's the only one that happened to.

I'd suggest resubmitting that result manually and see if that does it. If you run into a problem just let me know here and I'll check it out further.

I've submitted a few results manually since the new server went online and they all did okay so I'm pretty sure it's working, just not sure why yours had a problem.

I tried re-submitting the result myself and got an error:
"Error code: 48, error text: Residue cannot be 0x0000000000000000, check your program and/or GPU drivers"

Did you see that error when you did it too?

Anyway, something must be wonky in the parser that handles manual result text. I'll have to compare the raw message you submitted with a "normal" one and see if there was just something off about it or if the parsing code needs some adjustment.

I looked back at the past couple months for any others that might be the same, but still, yours was the only one where it logged it in the history but didn't mark it complete in the actual LL results data.

EDIT: I tried submitting that on the old server too and got the same error. Plus, I saw in that case that it added the "history" line just like you saw, but didn't properly log the result. So, not a new issue, but still an issue. I'm looking into it.

[GP2]

Originally Posted by Madpoo

I looked back at the past couple months for any others that might be the same, but still, yours was the only one where it logged it in the history but didn't mark it complete in the actual LL results data.

EDIT: I tried submitting that on the old server too and got the same error. Plus, I saw in that case that it added the "history" line just like you saw, but didn't properly log the result. So, not a new issue, but still an issue. I'm looking into it.

If the old server had the same problem, then the 2008-05-10 result from Anonymous was probably rejected in the same way.

So if it's at all feasible, we should look a lot further than just the past couple of months. Because it certainly looks like we have a second incident from more than 9 years ago.

Must be very rare though, since any exponent that is impossible to double-check would eventually stick out like a sore thumb. Maybe it's correlated with some very specific pattern in the residue?

[Madpoo]

Originally Posted by Madpoo

EDIT: I tried submitting that on the old server too and got the same error. Plus, I saw in that case that it added the "history" line just like you saw, but didn't properly log the result. So, not a new issue, but still an issue. I'm looking into it.

Ugh... this was painful, especially since I'm not too familiar with PHP.

There's some code that checks manual results for invalid residues... 0x2 and 0x0 (if the software also said it was NOT prime...something that actually happened sometimes).

The problem came down to the way residues are treated as text, but in the comparison it was apparently doing a cast to integer when checking against "0000000000000000", which was doing funny things, but apparently only sometimes? I don't know if it was treating it as boolean or something...

I don't know, it was weird. In PHP you can do a === instead of == to compare the value and type.

What it boils down to, since this check was put in place (mid July I think?), any manual result (only manual) with a partial residue beginning with zero would have done this.

The good news is the result is still logged and stored, just not added to the official LL result table. And since I already ran a query and only found this one example, it was truly a black swan event.

I can fix it with === and then I'll resubmit that result for you. That should take care of it now and in the future.

[Madpoo]

If you're really curious, here's the code I was testing and the funky match that takes place. (no harm posting the residue now since it's checked in and verified).

http://phptester.net/

<?php
$rd64='0E55078676173658';
$badres='0000000000000000';
echo 'before: $rd64='.$rd64.'<br>';
echo '$rd64 is type '.gettype($rd64).'<br>';
echo '$badres is type '.gettype($badres).'<br>';
if ($rd64 == $badres) {
  echo 'Bogus match: '.$rd64.'='.$badres.'<br>';
}

If there's some particular reason that residue would ever equal the value of the bad residue it's checking against, I'd love to know. It has me puzzled, and the best I can figure is the $badres is evaluating to boolean in the comparison, perhaps? It's baffling...

Using === fixes it, but I always like to know why something is fixed, just to soothe my soul.

[science_man_88]

Originally Posted by Madpoo

If you're really curious, here's the code I was testing and the funky match that takes place. (no harm posting the residue now since it's checked in and verified).

http://phptester.net/

<?php
$rd64='0E55078676173658';
$badres='0000000000000000';
echo 'before: $rd64='.$rd64.'<br>';
echo '$rd64 is type '.gettype($rd64).'<br>';
echo '$badres is type '.gettype($badres).'<br>';
if ($rd64 == $badres) {
  echo 'Bogus match: '.$rd64.'='.$badres.'<br>';
}

If there's some particular reason that residue would ever equal the value of the bad residue it's checking against, I'd love to know. It has me puzzled, and the best I can figure is the $badres is evaluating to boolean in the comparison, perhaps? It's baffling...

Using === fixes it, but I always like to know why something is fixed, just to soothe my soul.

my only thought is maybe checking interim results files was what it was for but a 0 before the final makes no sense, just a thought. BTW PARI/GP has === and == and = ( unless they suddenly changed things)

[S485122]

Just an idea : '0E55078676173658' is a bit like an number in scientific notation (of course with only 0 before the E is does not make sense to have a number behind the E but nevertheless it might be interpreted as that type of value.)

Jacob

[GP2]

Originally Posted by Madpoo

I can fix it with === and then I'll resubmit that result for you. That should take care of it now and in the future.

There's still a bit of weirdness. I don't know what to make of it, so I'll just describe it.

Right now, if you check the Exponent Status page for M41468027, it shows the following:

LL

Verified     2008-05-11     Arie Yakobovich     0E55078676173658
Verified     2017-08-13     monst               0E55078676173658

History

2017-08-12     monst           C     0E55078676173658
[...]
2008-05-10     -Anonymous-     C     0E55078676173658

But I still have an old Exponent Status window open from yesterday for this same exponent, and it shows (note the residue!!):

LL

Unverified     2008-05-11     Arie Yakobovich     AF19BE28CD3746__

History

2017-08-12     monst           C     0E550786761736__
2008-05-10     -Anonymous-     C     0E550786761736__

But here's the thing. I have old flatfile copies of the LL residues database, obtained by running a bot on the Reports: LL Results page.

And those contain the following line, as of both August 1 2017 and June 3 2016:

41468027,Arie Yakobovich,250851,0E550786761736__,,2008-05-11 03:52

It's the only line for that exponent.

(Yesterday I mentioned that my copies of the database contained no line for "Anonymous" for this exponent, which is true enough, but somehow I missed the name "Arie Yakobovich" staring me right in the face).


So... before today's fix, the Exponent Status page and the LL Results page were showing very different information for this exponent. The Exponent Status page had some mysterious residue AF19BE28CD3746__ (which can't be found anywhere in my copies of the database) for Arie Yakobovich whereas the LL Results page clearly had the correct residue 0E550786761736__ all along.

How is that even possible?

Can you search the old log files to try to see if this mystery residue AF19BE28CD3746__ occurs anywhere? Do the old log files contain a result returned by Anonymous on 2008-05-10, different from the one returned by Arie Yakobovich on 2008-05-11? And is there a glitch in the PHP code that causes different results to display sometimes for the Exponent Status page and the LL Results page, similar to the glitch that caused the manual reporting issue?

(Note: as mentioned yesterday, about 99% of the LL results in the database that have a timestamp in May 2008 have a date of either 2008-05-10, 2008-05-11 or 2008-05-22, so there was some kind of batching going on back then for adding results to the database.)