[QUOTE=Mark Rose;380366][url=http://v5www.mersenne.org/report_exponent/default.php?exp_lo=68743163&full=1]Nope[/url]. I just factored M68743163 with StopAfterFactor=2 in mfaktc, and this is all it produced: F-PM1 2463386658202793009209. No indication of the agent or that factoring was only partial for the bit depth.[/QUOTE]
Not sure if that result is representative. It looks like a TF that was interpreted by PrimeNet as P-1; did you report a no-factor found before the TF result to get around the P-1 bug?

[QUOTE=snme2pm1;380335]Me wonders as to the definition of "night", and impact on mersenne.org response to people's enquiries and submissions, prime95 and misfit.[/QUOTE]

Fortunately doing an index reorganization is an online task. Performance can be hit a bit since it's doing some disk I/O (well, a lot of disk I/O on large indices).

An index rebuild is an offline task except in the enterprise editions of SQL, which this definitely won't be (that's a lot of extra $$$), so that probably wouldn't happen except in some extreme circumstance. There are some clustered indices in use so during any rebuild there would probably be some features that wouldn't work that specifically use an indexed view, but I don't know for sure. Other queries could run okay but take longer without an index to help them along.

The best times of day to run any maintenance task whether it's SQL, doing a disk defrag, or anything else that impacts some subsystem, is best determined by looking at traffic levels over the course of a few weeks and finding those dips in activity.

I see that the web page is instrumented with Google Analytics which would help see how the web traffic does.

On the API side of things, check in and check out activity is timestamped so it should be fairly easy to gather in some stats for the last XX days or weeks and see if there's any type of pattern. Those are probably more evenly spread because clients don't care what time of day it is, they just check in/out as needed. But maybe there's something surprising in the data... maybe I can do a little analysis on the copy of the DB and see if anything pops out in that regard. Could be interesting, although I suspect it's fairly even.

[QUOTE=sdbardwick;380367]Not sure if that result is representative. It looks like a TF that was interpreted by PrimeNet as P-1; did you report a no-factor found before the TF result to get around the P-1 bug?[/QUOTE]

Ahh, nevermind. I was just going by what I could see on the web. The actual results submitted should look like:

M68743163 has a factor: 2463386658202793009209 [TF:71:72*:mfaktc 0.20 barrett76_mul32_gs]
found 1 factor for M68743163 from 2^71 to 2^72 (partially tested) [mfaktc 0.20 barrett76_mul32_gs]

[QUOTE=kladner;380362]These results included a Factor Found. I don't remember seeing the error below before:
[CODE]Processing result: nHTTP/1.1 502 Gateway Error Server: Microsoft-IIS/5.0[/CODE][/QUOTE]

Weird... 502 error is a gateway related error, like a proxy server in the path had an issue. There's no proxy directly in front of the current website... traffic goes directly to IIS from the outside world, not through a load balancer/caching proxy/whatever.

Any proxy seems like it'd be on the client's side, but the IIS/5.0 is kind of a giveaway that it did manage to hit the server in some way... might have been a request going through a proxy that timed out or something...that's my guess.

Last response from the server, 1754 UTC:
[QUOTE]
[B]Warning[/B]: odbc_pconnect() [[URL="http://www.mersenne.org/manual_result/function.odbc-pconnect"]function.odbc-pconnect[/URL]]: SQL error: [Microsoft][ODBC SQL Server Driver]Timeout expired, SQL state S1T00 in SQLConnect in [B]C:\v5\www\2013\v5server\0.96_database.inc.php[/B] on line [B]21[/B]
pnErrorResult=3 pnErrorDetail=Database unavailable ==END== [/QUOTE]In reference to my previous post, NF results were accepted. I still haven't gotten the Factor Found result to go through.

EDIT: I got in to submit results, but the response is the same. The NF results have already been accepted.
[QUOTE]Processing result: no factor for M68762963 from 2^73 to 2^74 [mfaktc 0.20 barrett76_mul32_gs]
Error code: 40,
error HTTP/1.1 502 Gateway Error
Server: Microsoft-IIS/5.0
Date: Thu, 14 Aug 2014 18:00:04 GMT
Connection: close
Content-Length: 186
Content-Type: text/html [B]
CGI Timeout[/B]

The specified CGI application exceeded the allowed time for processing. The server has deleted the process.[/QUOTE]

[QUOTE=Mark Rose;380366]No indication of the agent or that factoring was only partial for the bit depth.[/QUOTE]How was the result submitted? Manually? with misfit?

[QUOTE=Madpoo;380377]Weird... 502 error is a gateway related error, like a proxy server in the path had an issue. There's no proxy directly in front of the current website... traffic goes directly to IIS from the outside world, not through a load balancer/caching proxy/whatever.

Any proxy seems like it'd be on the client's side, but the IIS/5.0 is kind of a giveaway that it did manage to hit the server in some way... might have been a request going through a proxy that timed out or something...that's my guess.[/QUOTE]

While not IIS, I've seen 502's happen with an Nginx+PHP sitation, where PHP fails. If PHP is not in-process, like it often is in Apache, in IIS, a PHP issue may have been what caused that.

[QUOTE=James Heinrich;380380]How was the result submitted? Manually? with misfit?[/QUOTE]

By calling this file: [url]https://github.com/MarkRose/primetools/blob/master/mfloop.py[/url]

It should send every line from mfakt?'s results.txt with a mersenne number string (M123456...) in it.

[QUOTE=Madpoo;380377]Weird... 502 error is a gateway related error, like a proxy server in the path had an issue. There's no proxy directly in front of the current website... traffic goes directly to IIS from the outside world, not through a load balancer/caching proxy/whatever.[/QUOTE]

I can support the observation that "502s" are quite common. Is it possible that Primenet is behind a proxy you don't know about?

I can further say but (quickly checking some of my spider's logs) can't document that such errors are highly correlative with other errors, such as "CGI Timeouts", "Database unavailable", etc.

If it would help I could instrument my spiders to collect deeper error statistics.

[QUOTE=sdbardwick;380367]It looks like a TF that was interpreted by PrimeNet as P-1[/QUOTE]I would tend to agree. I would poke a little closer at the data... if mersenne.org was working right now.

Once we get the server migrated and more responsive I'll re-implement my results parsing code and hopefully put the whole misinterpreted results issue behind us.

[QUOTE=James Heinrich;380389]I would tend to agree. I would poke a little closer at the data... if mersenne.org was working right now.

Once we get the server migrated and more responsive I'll re-implement my results parsing code and hopefully put the whole misinterpreted results issue behind us.[/QUOTE]

I'm trying to login to the current server right now and it's being exceptionally slow, so I'm not sure what's up. I'll probably just look and not touch in case George is already on there as well checking on it. Unless I see something obviously broken, there's the "too many cooks" thing and George would know from past experience what the problem probably is.