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

[GP2]

Originally Posted by Madpoo

I know some of y'all are just hoping I'd do some other updates, even relatively minor like switching to nvarchar for a few things (user/cpu names)... I'll get there in time.

Just a quick summary for those who don't realize why nvarchar (Unicode fields in the SQL Server database) might be desirable:

Currently, any new or modified public User name is limited to alphanumerical ASCII characters plus underscore and hyphen, as at https://mersenne.org/update/

However, there are a lot of legacy User name values inherited from Primenet version 4 which didn't have that limitation, and some of those contain non-ASCII 8-bit characters.

GIMPS has been around for more than twenty years, since the earliest days of the modern web, and in those early days, websites and browsers mostly didn't use Unicode; rather, the browser could be switched between 8-bit character sets, much like "code pages" in the Windows console. So users around the world had their browsers set to the 8-bit character set of their choice, and created their usernames accordingly.

So the database already contains User names with European letters, Cyrillic, even Chinese, Japanese and Korean, except instead of Unicode they're encoded in 8-bit form, sometimes including non-printing characters in the range 0x80 to 0x9f. The site mersenne.org currently displays webpages in Latin-1.

So, Western European names that can be encoded in Latin-1 display normally, although there are a few cases of excessive UTF-8-ification like "Esaú" instead of "Esaú". Eastern European names have incorrect letters, like £ and ñ instead of Ł and ń. And the non-Latin writing systems are just alphabet soup.

The overwhelming majority of these User names are simply the names of people, although a few are monikers of various kinds. So in nearly all such cases, it's possible to (manually) figure out which legacy 8-bit character set the user used and therefore decode it back to Unicode. I've already done this for user names which have returned at least one LL result, although there are probably a lot of people who registered but never returned any results, whose usernames are therefore not externally visible.

[GP2]

Originally Posted by Madpoo

Ding ding ding, you get the prize. (oh, and the final two digits of the phony residue don't actually exist, it's literally rendered with "__" but I guess it might have been "55" )

I put a failsafe in the exponent report that would only be triggered if all other methods of "hiding" new primes from being reported were to fail. It would display a phony residue (which I'll now have to change, LOL)

I just thought of something.

Your response ("a phony residue which I'll now have to change") indicates that you use a single fixed value for this purpose.

However, there have been two actual cases where a Mersenne prime was discovered but no one noticed it until months later, due to a failure of the e-mail alert mechanism. What would happen if someone actually completed a double check before anyone realized that the first-time test had discovered a prime?

If a new Mersenne prime discovery was missed on both the first-time test and the double-check, and the same phony placeholder residue was attached to both results, could it conceivably end up in the database as a verified non-prime, with no one the wiser?

Is it remotely possible that this might have happened already?

Wouldn't it be better to just generate a purely random value each time for the phony placeholder residue? That way, it would never match no matter how many times a result was returned, and even in the worst-case scenario it would simply accumulate triple checks and quadruple checks and more until it got someone's attention. An added benefit of a purely random number is that no one could use clever guesswork or numerological considerations to distinguish a phony residue from a real one and thereby guess the identity of a new prime exponent before the official reveal (as has happened numerous times in the past).

[Madpoo]

Originally Posted by GP2

...
If a new Mersenne prime discovery was missed on both the first-time test and the double-check, and the same phony placeholder residue was attached to both results, could it conceivably end up in the database as a verified non-prime, with no one the wiser?

Is it remotely possible that this might have happened already?
...

Nope. The phony residue is only ever sent as a substitute on the web server, not stored anywhere. And it is just a last-ditch failsafe to prevent a new, unannounced prime, from showing up anywhere in a report or website. In theory, any like that wouldn't show up in a report at all. The only reason that didn't work in this case is because the exponent wasn't *really* zero, PHP only thought it was thanks to it's "fuzzy" matching.

As for missing any new primes coming in, like last time, there's a pretty good system in place now to make sure new primes being reported in (whether automatically or by the manual results page) will trigger an email. On top of that there's a weekly job that runs again just to confirm. Those weekly emails will send whether it finds anything or not which also helps make sure the email itself is operational.

And if that wasn't enough, I do still do an occasional query for any new results with a zero residue, including the funky ones where the residue is zero but it reported as composite somehow.

[petrw1]

The Recent Cleared page used to always have a couple dozen results of people finding the same small factors for Fermat12: 4096 (I was guilty too until I fixed the assignment to add current factors).

However, lately I don't see these any more.

Related, I think. I had a PC re-find factors twice for F19: 524288 (oops forgot to add those to the assignment)

They do NOT show up in my results.
And according to my math I also did NOT get the GhzDays.

However, prime.log has this:

[Tue Aug 29 14:28:58 2017 - ver 28.9]
Sending result to server: UID: petrw1/Emperor_Zurg, F19 has a factor: 70525124609 (ECM curve 1, B1=44000000, B2=4400000000), AID: 7B4CFC7E0C4E14AB6A1002A1FF1E28CD

URL: http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=ar&g=2dccc56ca93aa1ba03781ea9d7a036b3&k=7B4CFC7E0C4E14AB6A1002A1FF1E28CD&m=UID:+petrw1/Emperor_Zurg,+F19+has+a+factor:+70525124609+(ECM+curve+1,+B1=44000000,+B2=4400000000),+AID:+7B4CFC7E0C4E14AB6A1002A1FF1E28CD%0A&r=3&d=1&A=1&b=2&n=524288&c=1&CR=1&B1=44000000&stage=1&B2=4400000000&f=70525124609&fftlen=30720&ss=41&sh=71B0AD23B7FBE35DB59EF9A34CC39390
RESPONSE:
pnErrorResult=0
pnErrorDetail=Already have ECM factor 70525124609 for 2^524288+1
CPU credit is 14.4669 GHz-days.
==END==

PrimeNet success code with additional info:
Already have ECM factor 70525124609 for 2^524288+1
CPU credit is 14.4669 GHz-days.

. . . . . .  and a little later . . . . . . 

[Wed Aug 30 11:46:11 2017 - ver 28.9]
Sending result to server: UID: petrw1/Emperor_Zurg, F19 has a factor: 70525124609 (ECM curve 1, B1=44000000, B2=4400000000), AID: 7C486C9F3FF5D726578FA687FD01EA7B

URL: http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=ar&g=2dccc56ca93aa1ba03781ea9d7a036b3&k=7C486C9F3FF5D726578FA687FD01EA7B&m=UID:+petrw1/Emperor_Zurg,+F19+has+a+factor:+70525124609+(ECM+curve+1,+B1=44000000,+B2=4400000000),+AID:+7C486C9F3FF5D726578FA687FD01EA7B%0A&r=3&d=1&A=1&b=2&n=524288&c=1&CR=1&B1=44000000&stage=1&B2=4400000000&f=70525124609&fftlen=30720&ss=41&sh=5546C2A355DD6AC17D457B7BC429A4E2
RESPONSE:
pnErrorResult=0
pnErrorDetail=Already have ECM factor 70525124609 for 2^524288+1
CPU credit is 14.4669 GHz-days.
==END==

PrimeNet success code with additional info:
Already have ECM factor 70525124609 for 2^524288+1
CPU credit is 14.4669 GHz-days.

[Madpoo]

Originally Posted by petrw1

The Recent Cleared page used to always have a couple dozen results of people finding the same small factors for Fermat12: 4096 (I was guilty too until I fixed the assignment to add current factors).

However, lately I don't see these any more...

I did a cleanup... multiple entries in the "history" were cleaned up.

By multiple entries, I mean everything was exactly the same (same client text, even the same assignment ID if it was there).

I don't know if there was a bug in the server that had accepted duplicate results like that in the past or if it was some weird quirk, but yeah... that even included people reporting the same LL results multiple times (same shift count, exponent, residue, assignment ID, etc).

On factors some exponents (or that Fermat # you mentioned) had people reporting the same factors over and over... it was annoying to look at a report for that exponent and see a big history of people reporting the same crud.

So, only the earliest known result was kept in those cases.

This only affected the "history" section... there's already code in place to keep the same factor or LL residue (from the same user/shift count/assignment) from being recorded multiple times, but it was still showing up in the raw log, that's all. Now gone.

[petrw1]

Originally Posted by Madpoo

I did a cleanup... multiple entries in the "history" were cleaned up.

By multiple entries, I mean everything was exactly the same (same client text, even the same assignment ID if it was there).

I don't know if there was a bug in the server that had accepted duplicate results like that in the past or if it was some weird quirk, but yeah... that even included people reporting the same LL results multiple times (same shift count, exponent, residue, assignment ID, etc).

On factors some exponents (or that Fermat # you mentioned) had people reporting the same factors over and over... it was annoying to look at a report for that exponent and see a big history of people reporting the same crud.

So, only the earliest known result was kept in those cases.

This only affected the "history" section... there's already code in place to keep the same factor or LL residue (from the same user/shift count/assignment) from being recorded multiple times, but it was still showing up in the raw log, that's all. Now gone.

OK good to know. I agree with not accepting and reporting the same factor over and over.
And just to be clear, then the partial credit reports is also not being given?

Thanks

[Madpoo]

Originally Posted by petrw1

OK good to know. I agree with not accepting and reporting the same factor over and over.
And just to be clear, then the partial credit reports is also not being given?

Thanks

I don't know if any extra credit was ever actually given in those cases. There's certainly no reason to get credit if you're turning in a factor that was already known, for example.

In most of the cases (probably 90% of the duplicates I saw) it was a case of the same assignment checking in twice. For the other cases, it was people checking in already-known-factors or P-1 results.

I was just looking at the code to log results and there is a little thing in there that will log the result even if it's a duplicate, for later review, so that's probably all it was. I reviewed them.

[petrw1]

Originally Posted by Madpoo

I don't know if any extra credit was ever actually given in those cases. There's certainly no reason to get credit if you're turning in a factor that was already known, for example.

In most of the cases (probably 90% of the duplicates I saw) it was a case of the same assignment checking in twice. For the other cases, it was people checking in already-known-factors or P-1 results.

I was just looking at the code to log results and there is a little thing in there that will log the result even if it's a duplicate, for later review, so that's probably all it was. I reviewed them.

I'm ok either way.

But as far as the facts:
- I did NOT get credit for the re-Factors
- By the time I fixed the assignments a couple days later there were 7 re-Factored of this same 524,288; all on curve 1....so maybe they all had the same AID; though I didn't think so.
- There are still a lot of 4096 Factors getting re-reported lately.

[Madpoo]

Originally Posted by petrw1

I'm ok either way.

But as far as the facts:
- I did NOT get credit for the re-Factors
- By the time I fixed the assignments a couple days later there were 7 re-Factored of this same 524,288; all on curve 1....so maybe they all had the same AID; though I didn't think so.
- There are still a lot of 4096 Factors getting re-reported lately.

Yeah... Fermat stuff... I have honestly not looked into that stuff on the server. Not even sure how Primenet wound up tracking that stuff but whatever.

For ECM stuff I left those alone. It's common for a single assignment to check in multiple times (at least, it seemed that way) with the same parameters/number of curves. Or, at the very least, there's no good way to know for sure if it's the same result being checked in, or a new one with the exact same # of curves as before. Timestamps might give a clue, but I didn't want to dig into it that much.

[Mark Rose]

Originally Posted by Madpoo

I don't know if any extra credit was ever actually given in those cases. There's certainly no reason to get credit if you're turning in a factor that was already known, for example.

How about poached TF work?

[Madpoo]

Originally Posted by Mark Rose

How about poached TF work?

If you had an assignment, in general you'll get credit even if it was no longer needed.

For example, if you were assigned some LL work and someone turned in a factor for that exponent, if you finish you'll get the credit even though no LL tests are needed anymore.

I think the same holds true if you had a TF or P-1 assignment and someone else turns in a factor. The key there is having an assignment for it.

For LL tests on already-verified exponents, I found that even if you don't have an assignment, you'll still get credit. All of my (and others) triple-checks to independently verify stuff showed that.