[QUOTE=ric;380841]UPDATE: results are now received (20:45 CEST). Big thanks to whomever solved the first point in such a short while!

First, as already notified by chalsall, is (times in CEST):

[CODE]
[Comm thread Aug 19 19:45] Sending result to server: UID: RU/Xeon12C, M279032531 no factor from 2^66 to 2^67, We4: <redacted>, AID: <redacted>
[Comm thread Aug 19 19:45] PrimeNet error 13: Server database full or broken
[Comm thread Aug 19 19:45] ar Insert t_gimps_results_log failed: RU GUID: <redacted>, exponent: 279032531, C2D_CPU_GHz_days: 0.0535617818
[/CODE]

Second is a somewhat erratic behaviour of the actual assignments page, which at times seems to "forget" some exponents - or to put them out of sequence - a reload after a short while usually makes them reappear.

TIA :smile:
ric[/QUOTE]

James is currently crawling through the PHP error log and identifying things like that. Some of them were just warning messages that we think had always been there but were harmless enough, but James is getting the code up to date.

I won't presume to speak for him on what other oddities he's found, but he's squishing bugs at this very moment.

On the off chance some results were attempted to check in but failed, and the client didn't retry them, we should be able to look through the server logs and locate those. I think the client gets an error back from the server and will retry again in 60 minutes or whatever it's set to.

Manually submitted forms that generated an error should be retried by the user at their leisure. They would have seen an error and would know to try again, I presume. :smile:

[QUOTE=kracker;380843]Warning: odbc_exec(): SQL error: [Microsoft][ODBC SQL Server Driver][SQL Server]Could not find stored procedure 'master..XP_IsFactorOK'., SQL state 37000 in SQLExecDirect in C:\inetpub\www\2013\v5server\0.96_database.inc.php on line 130[/QUOTE]Fixed.

[QUOTE=James Heinrich;380820]I just fixed some missing include files in the manual results, but that shouldn't have given a 404 error. What kind of results were you submitting? Do you have the URL of the not-found page?[/QUOTE]

Still broke, exactly the same error message. Start of url is

[url]http://www.mersenne.org/manual_result/default.php?data=UID%3A+nitro%2FNVidia%2C+no+factor+for+M45724493+from+2%5E68+to+2%5E69+%5Bmfaktc+0.20+barrett76_mul32_[/url] .........

Submitting gpu trial factoring via the manual results submission page

Update: it does however accept the results if you upload a text file

The error message in kracker's post above is what I mentioned a couple of posts above.

[QUOTE=Gordon;380847]Still broke, exactly the same error message.[/QUOTE]I'm unable to replicate with already-known no-factor or factor results. Perhaps it is related to reporting a new result. Can someone who has seen this problem confirm this?

I was just now able to report results manually.

Thanks, James. :tu:

Rodrigo

[QUOTE=James Heinrich;380850]I'm unable to replicate with already-known no-factor or factor results. Perhaps it is related to reporting a new result. Can someone who has seen this problem confirm this?[/QUOTE]

Just to put this out there...

I will never forget the [URL="http://en.wikipedia.org/wiki/Gimli_Glider"]Gimli Glider[/URL]

[QUOTE=James Heinrich;380850]I'm unable to replicate with already-known no-factor or factor results. Perhaps it is related to reporting a new result. Can someone who has seen this problem confirm this?[/QUOTE]

Just tried again with cut'n'paste and it accepted them

Working now! :wink:

Thanks.

[QUOTE=Gordon;380856]Just tried again with cut'n'paste and it accepted them[/QUOTE]

I just tried the manual results - upload a file with a 303 result 29k file. Worked fine, previously it would sit for minutes on end apparently doing nothing.

This time - about 5 seconds. Very impressed.

[QUOTE=Gordon;380864]I just tried the manual results - upload a file with a 303 result 29k file. Worked fine, previously it would sit for minutes on end apparently doing nothing.

This time - about 5 seconds. Very impressed.[/QUOTE]

Yeah, James and George are getting some kinks worked out. Some things were what I'd call legacy bugs, where things would throw warnings but the PHP logging wasn't showing them. We have logging turned up a little higher so we can see what's happening and there were some things in there.

The server itself is doing very well. I'm looking at real time performance graphs and CPU usage is surprisingly busy... I mean, it's 20% on average, but on the old server it never really got that high. This is with 8 cores, by the way.

I think the old server was so hamstrung by the slow disk I/O and limited memory that the CPU was just never all that stressed. Now that other subsystems have caught up, we're finally seeing the CPU get a workout.

I forgot what I saw previously for SQL tps... maybe I mentioned it before. But right now it's averaging 17-20 transactions per second, but that's not really the full story because it's very bursty. It's usually pretty low, like single digits, but then has periods where it bursts up to 85-100+ for a short time. That might be when results are being checked in or when someone hits certain things on the website.

It could probably handle much more... those peaks in TPS don't show much in the way of increased CPU or anything.

Disk queue lengths are negligible... they're averaging zero, so it's really not waiting on the drives at all for anything. The nice thing I'm seeing is a very low pages/sec, averaging only a couple dozen. The extra memory is really helping.

Now, I'll have to admit that on the virtual server it's running on, I only gave it 16 GB of RAM because it started out as a test box to see if the code would even run. I really need to give it more. I think I can give it another 16 GB no problem, I'll just have to shut it down at some point for a few seconds.

I'd actually forgotten I only gave it 16 instead of 32 until I started looking at the usage and saw I only had 16 GB of RAM assigned. Regardless, it's doing pretty well. SQL sucked up all the RAM it could within a short time of going live yesterday, so it does like the memory. I'll be curious to see what happens when I give it 32 GB. Will it fill that all up too, or will it reach some Q point before that? Maybe I should keep feeding it memory and see where the Q point actually lives.

Also FYI, I shrunk the database because of that 54 GB total size, 12 GB was empty. So it's really only 42. And of that 42, over half is indexes... so when you get right down to it, the data isn't excessively large after all. I've sneezed out larger databases than that. :ick: