Register FAQ Search Today's Posts Mark Forums Read

2015-04-11, 23:41   #936
Serpentine Vermin Jar

Jul 2014

63158 Posts

Quote:
 Originally Posted by James Heinrich Some exponents have factors displayed incorrectly: e.g. http://www.mersenne.org/M66362159: Code: result: M66362159 has a factor 124246422648815633 display: Factor: 159 Also noticed on M66001631 and M66000007.
Looking at M66362159 (and the others). The commonality there seems to be some lines are missing a colon in the text:

M66362159 has a factor: 9157977943
M66362159 has a factor 124246422648815633

First one has the colon after "factor", second one doesn't. I guess the pretty parsing is choking on that second line.

In those 3 cases at least, the ones with missing colons all came on the same day, 2009-12-05, and the same user "TheJudger", same computer and same app version "Unknown,(aka U)"

If I expand on that and look for any cases where the text is like that (missing a colon entirely), there are 22 total, all from the same user, computer and weird unknown app version. Customized build of the code from source?

There are another 28 results for factors found where the format is similar, but it does have a colon, just with an extra space before it. All from user "TJAOI". Those seem to be parsing okay though since it's really looking for the colon as a separator, doesn't matter if there's that extra space.

I guess the lesson is, if you're customizing your own build, please try to leave the results format unchanged... the server has to parse that and there's already a long list of ways it has to handle things from all the older builds and other executables out there.

***
Also, I think someone's crawling the server right now and the website is taking a long time to serve up pages. I'm trying to figure out if it's heavy activity, or the server being sluggish, etc. Overall system load is pretty low so it might be something waiting on a long SQL query and it's bottlenecked some things. If you see the server unavailable entirely for a few seconds, it might be because I had to reset IIS to unstick the logjam.

2015-04-11, 23:44   #937
James Heinrich

"James Heinrich"
May 2004
ex-Northern Ontario

55 Posts

Quote:
 Originally Posted by Prime95 You could delete the meaningless DB entry. That would make the result just like all results up to November 2008 -- the result text was not recorded.
I agree -- where it's non-trivial to reconstruct what the entry should say (e.g. "no factor") just delete the non-information.

Quote:
 Originally Posted by Madpoo ... the same user "TheJudger"
Yeah, he's a real trouble-maker that one
(author of mfaktc if you didn't know, so quite probable that those were initial results found by the first development version of mfaktc, with an apparent typo in the results format.

Last fiddled with by James Heinrich on 2015-04-11 at 23:49

2015-04-11, 23:49   #938
Serpentine Vermin Jar

Jul 2014

29·113 Posts

Quote:
 Originally Posted by lycorn Anything wrong with mersenne.org? I can´t get to the site, although I´m able to access any other site at will. (Seems like chalsall has beaten me to it...)
Yeah, someone's doing some heavy lifting on the website... haven't nailed it down, but I reset IIS to clear up some old PHP threads. It's still sluggish because whatever's causing the traffic jam is still going on.

And for George, I actually got an alert about the site issue about 15 minutes ago from Pingdom which checks the home page. It let me know it was timing out.

2015-04-11, 23:52   #939
James Heinrich

"James Heinrich"
May 2004
ex-Northern Ontario

55 Posts

Quote:
 Originally Posted by Madpoo I think someone's crawling the server right now and the website is taking a long time to serve up pages.
I confess.

I have been crawling over the last couple days (hence my discovery of so many "problems"), but mersenne.org has been completely non-responsive to me for about 2 hours, so I'm not crawling right now.

Last fiddled with by James Heinrich on 2015-04-11 at 23:55

2015-04-12, 00:04   #940
Serpentine Vermin Jar

Jul 2014

29·113 Posts

Quote:
 Originally Posted by James Heinrich I confess. I have been crawling over the last couple days (hence my discovery of so many "problems"), but mersenne.org has been completely non-responsive to me for about 2 hours, so I'm not crawling right now.
Well, if that was it (and I don't know for sure), we probably need to tighten up some queries and make sure they're non-locking to start with.

I appreciate the weird things you found in your crawl. Helps us make sure the stuff we're outputting is good stuff.

2015-04-12, 01:28   #941
Serpentine Vermin Jar

Jul 2014

1100110011012 Posts

Quote:
 Originally Posted by Madpoo Well, if that was it (and I don't know for sure), we probably need to tighten up some queries and make sure they're non-locking to start with.
It might be the GPU72 spider? I really can't tell... I've received a few more alerts from the site monitoring about the home page taking too long to load. I looked at the logs for anything hitting the site frequently in the past 15 minutes and the GPU72 spider is doing a good amount of work pulling factoring reports in different 1M ranges and requesting assignments.

But nothing really out of the ordinary there as near as I can tell, but to be honest I'm not sure what that activity would normally look like. I just see that it's requests are taking 10+ seconds, up to 70-80 in some cases, but then everything is kind of slow during these periods of time.

EDIT: I can't help but feel I forced folks into spidering things because I mucked up the hourly reports with my thousands of triple-checks.

Last fiddled with by Madpoo on 2015-04-12 at 01:30

2015-04-12, 14:54   #942
chalsall
If I May

"Chris Halsall"
Sep 2002

2×4,643 Posts

Quote:
 Originally Posted by Madpoo It might be the GPU72 spider? I really can't tell...
Don't think GPU72 was the problem -- it wasn't doing anything it doesn't normally do. BTW, Primenet began responding normally again at 2350.

 2015-04-12, 15:04 #943 James Heinrich     "James Heinrich" May 2004 ex-Northern Ontario 55 Posts I've noticed an inconsistency between XML and HTML output for LL results where the exponent has been factored after getting a matching double-check: M8966299 vs xml HTML shows full residue for matching tests, but XML still shows a masked residue even though the residue is verified. Is that easily changed, or would that make the complex SQL even uglier? If not too hard, it would be nice to have the full residue in the XML output for verified results. Last fiddled with by James Heinrich on 2015-04-12 at 15:04
2015-04-12, 20:06   #944
Serpentine Vermin Jar

Jul 2014

63158 Posts

Quote:
 Originally Posted by James Heinrich I've noticed an inconsistency between XML and HTML output for LL results where the exponent has been factored after getting a matching double-check: M8966299 vs xml HTML shows full residue for matching tests, but XML still shows a masked residue even though the residue is verified. Is that easily changed, or would that make the complex SQL even uglier? If not too hard, it would be nice to have the full residue in the XML output for verified results.
Oh good, that was an easy one. The XML was masking when the result was anything but "verified". In that example the LL results got marked differently because a factor was found later.

I just modified the code to show the unmasked residue if the result is either "verified" or "factored". There might be cases where an exponent has only been first-time checked, not verified, and then a factor is found. In those cases, that unverified result gets marked as "factored" and that solo residue is now shown in it's full glory, but I think the normal non-XML will do that now and once it's factored I don't think it really matters as far as integrity of results. It might encourage someone to forge a matching result line that matches as some lame attempt at getting credit, but they could do that now by submitting tons of triple checks. And no, I'm not doing that with all of my triple checks. LOL

I wonder too if there's any point in masking a "bad" residue, as that same example shows. Seems like maybe the only time it should be masked is if the result is either "unverified" or "suspect". Often, a bad residue will look like 0x0000000000000002 and when that last "02" is masked, people might mistakenly think it's a "secret" prime.

 2015-04-13, 13:10 #945 lycorn     Sep 2002 Oeiras, Portugal 2·19·37 Posts 13:05 UTC: Server is real sluggish. Pages take ages to load, sometimes don´t load at all.
2015-04-14, 05:00   #946
Serpentine Vermin Jar

Jul 2014

29×113 Posts

Quote:
 Originally Posted by lycorn 13:05 UTC: Server is real sluggish. Pages take ages to load, sometimes don´t load at all.

Honestly, I don't know what it is and I haven't had time to parse the logfiles to see who or what is hitting the website so much.

It's been quiet the rest of the day though. If it's still acting up tomorrow I'll renew my attempts to figure out what's going on. Tomorrow is "patch Tuesday" anyway and it may be a good opportunity to get the server caught up on updates and reboot to clear out any gremlins.

 Similar Threads Thread Thread Starter Forum Replies Last Post ewmayer Lounge 39 2015-05-19 01:08 ewmayer Science & Technology 41 2014-04-16 11:54 cheesehead Soap Box 56 2013-06-29 01:42 cheesehead Soap Box 61 2013-06-11 04:30 Dubslow Programming 19 2012-05-31 17:49

All times are UTC. The time now is 07:19.

Tue Oct 27 07:19:54 UTC 2020 up 47 days, 4:30, 0 users, load averages: 1.25, 1.40, 1.53