OFFICIAL "SERVER PROBLEMS" THREAD

[Madpoo]

Originally Posted by kladner

Here's the latest I got from P95 trying to call home:

That's using GPU72 I imagine? Chris had mentioned an issue yesterday with a change to the manual results page. Sounded like it got fixed though so I'm not sure.

I don't see any hits involving exponent 32964923 today except some calls to check on it's status such as the simplified version of this type of URL:
http://www.mersenne.org/report_expon...&text=1&full=1

(the hits came from the GPU72 bot)

[kladner]

That's using GPU72 I imagine?

Yes, via the proxy setting.

[James Heinrich]

That's a weird message. That's got chalsall's name all over it and it's running Apache on CentOS, but claims to be v5.mersenne.org (which doesn't run Apache, or CentOS, not have Chris as an admin)
It would appear to be GPU72, but I'm not sure why it claims to be v5.mersenne.org at the bottom?

[Mark Rose]

GPU72 was having problems earlier today. It was running super slow. Requests would eventually complete after some minutes, so I wouldn't be surprised if something on that box was having issues.

[Madpoo]

Originally Posted by James Heinrich

That's a weird message. That's got chalsall's name all over it and it's running Apache on CentOS, but claims to be v5.mersenne.org (which doesn't run Apache, or CentOS, not have Chris as an admin)
It would appear to be GPU72, but I'm not sure why it claims to be v5.mersenne.org at the bottom?

This is where my utter ignorance of how GPU72 works comes in again. Do clients who use it use a proxy (or the app has one built in) that routes v5.mersenne.org traffic through the GPU72 box for checking in/out assignments? I guess that makes sense in a way so the GPU72 server can optimize the types of work it gets and reserve it's own blocks of exponents.

My guess is that the GPU72 server is having issues. I can sympathize since I've broken the mersenne.org web and API sites a couple times already in just a few short weeks.

[Robert_JD]

...when I submit my latest LL results, I still get this php error message:

[Madpoo]

Originally Posted by Robert_JD

...when I submit my latest LL results, I still get this php error message:

Hmm... that might be something George needs to take a look at.

First off, we still shouldn't be showing the SQL error to the end user. :)

Second, the error is this:

Cannot insert the value NULL into column 'app_version_id', table 'PrimeNet.dbo.t_gimps_results_log'; column does not allow nulls.

George made some DB changes the other day to help with index sizes, and if I recall, one of them involved that very thing, about some columns allowing nulls.

It sounds like your client doesn't have a value for the app version or it's not getting the right indexed value for it based on whatever it's set to.

As an aside, I have to hand it to George and James because I'm sitting here looking at the PHP temp files from the manual result submissions, and it's crazy how many different formats of text get pasted in there from different builds of the client. Somehow the code has to parse all of these different ways the data is coming in and make some sense of it.

James is testing a new manual submission page and looking for beta testers, so be sure to PM him if you're interested.

[patrik]

Originally Posted by Robert_JD

...when I submit my latest LL results, I still get this php error message:

I get the same error, and it seems (from the My Account/Results page) that the exponent is not accepted.

[Madpoo]

Originally Posted by patrik

I get the same error, and it seems (from the My Account/Results page) that the exponent is not accepted.

Well harumph. Yeah, I found the error in the PHP log which has the actual SQL insert it's trying to do, and there's no app id, just like it said.

I don't know what the expected behavior should be when a manual result comes in without an app version to store. Is it supposed to use a default value, or blank, or is there something else going on...

Just have to wait for George or James to take a peek. Check back tomorrow.

[Madpoo]

Originally Posted by Madpoo

Well harumph. Yeah, I found the error in the PHP log which has the actual SQL insert it's trying to do, and there's no app id, just like it said.

I don't know what the expected behavior should be when a manual result comes in without an app version to store. Is it supposed to use a default value, or blank, or is there something else going on...

Just have to wait for George or James to take a peek. Check back tomorrow.

FYI, my best guess is that in the results, your client identifies itself as "CUDALucas v2.05" but in the database there's a version ID for "CUDALucas v2.05 Beta". If it's trying to lookup that internal app version id based on the text matching, then it won't.

I don't suppose 2.05 came out of beta recently and you're all running a new version? :)

[Mark Rose]

Originally Posted by Madpoo

This is where my utter ignorance of how GPU72 works comes in again. Do clients who use it use a proxy (or the app has one built in) that routes v5.mersenne.org traffic through the GPU72 box for checking in/out assignments? I guess that makes sense in a way so the GPU72 server can optimize the types of work it gets and reserve it's own blocks of exponents.

My guess is that the GPU72 server is having issues. I can sympathize since I've broken the mersenne.org web and API sites a couple times already in just a few short weeks.

Chris is apparently busy lately, so I can give a brief overview from my understanding. Basically, as you suspect, it sometimes works as a proxy and sometimes like a cache.

For Trial Factoring, GPU72 reserves candidates from mersenne.org using a couple of special accounts ("For Research" and "Trial Factoring", IIRC). Client applications then request TF work from GPU72. When the TF client is finished the work, it submits it straight to mersenne.org. P-1 factoring is done much the same way. GPU72 knows which TF and P-1 assignments it has given to clients and periodically crawls mersenne.org to check for updates. If TF level isn't to the "release" level, GPU72 holds on to the candidate and issues it to another client that is willing to TF higher or do the P-1 factoring. If the TF level is at or above the "release" level, and P-1 factoring is done, GPU72 unreserves the candidate from mersenne.org. If GPU72 detects that mersenne.org is about to run out of candidates TF'ed to a high level for the various assignment rules it will unreserve higher TF'ed candidates that may not have had full TF or P-1 factoring (aka spidey's ripcord). DCTF works the essentially the same as LLTF.

GPU72 used to (still does?) handle some low-exponent LL assignments in a similar way, but only certain people's GPU72 accounts had been granted access. As far as I know GPU72 doesn't cache or hold on to any LL work.

For convenience, GPU72 also speaks the v5 API. This allows people to configure Prime95/mprime to talk to GPU72 to get assignments, and in the case where GPU72 has nothing reserved itself (normal) it can simply proxy the request to mersenne.org. Another perk of using GPU72 as a proxy is that GPU72 keeps track of the work given through the proxying, like done for TF, and will add it to the worker progress graphs.

Again, that's just my understanding of it.