[QUOTE=Prime95;380039]I'm 99% there. Thanks, James. The only remaining issue is generating a unique filename for YAFU to write to instead of the fixed siqs.dat.[/QUOTE]

I don't know how PHP does it, but a call to the system's GUID generator should ensure uniqueness. I'm just assuming PHP has something like that, otherwise a randomly generated one is probably just as good.

[QUOTE=Madpoo;380042]I'm just assuming PHP has something like that, otherwise a randomly generated one is probably just as good.[/QUOTE]

[url]http://php.net/manual/en/function.com-create-guid.php[/url]

[QUOTE=Prime95;380030]Since I am not familiar with either PARI or YAFU, do you recommend one over the other?[/QUOTE]I have PARI/GP working very nicely on both Windows and *nix. I can't say the same for either yafu or msieve (not saying it can't be done, I just haven't managed it).

My preference is for PARI/GP, it works well for me.

[QUOTE=Prime95;380040]People fought replacing P95-years for a long, long time. I suspect they'd fight changing GHZ-days too.[/QUOTE]

Oh, keep the GHz-day as a unit, but just recalibrate it to say, a Haswell instead of a Core 2 Duo.

[QUOTE=Prime95]I'm still getting several DCs a day from v4 computers. It turns out people are still downloading v24 prime95. Apparently, one can still create new v4 user IDs, get work, and report results. There is a PHP script that turns v4 requests into v5 requests, so there is no reason not to continue supporting v4 computers.[/QUOTE]

Wow, never would have thunk it. We probably should get any mirror sites to update their outdated Prime95 links as we catch them.

[QUOTE=Prime95;380039]I'm 99% there. Thanks, James. The only remaining issue is generating a unique filename for YAFU to write to instead of the fixed siqs.dat.[/QUOTE]

Md5 hash of the input number should be good enough.

I just got a CGI timeout on a batch of mfaktc results which included two factors. 0300 UTC, 8/10/2014.

The [URL="http://mersenne.org/report_recent_cleared/"]recent cleared[/URL] list shows only C for composite and no F for factor for a couple of hours, which is very counterintuitive, or a sign of something being wrong.

[QUOTE=tha;380119]The [URL="http://mersenne.org/report_recent_cleared/"]recent cleared[/URL] list shows only C for composite and no F for factor for a couple of hours, which is very counterintuitive, or a sign of something being wrong.[/QUOTE]

The factors were the hangup. This morning (my time) the entire set of results went through. All the NF results came up with Error 40, not needed. The two factors cleared and displayed credit.

[QUOTE=kladner;380124]The factors were the hangup. This morning (my time) the entire set of results went through. All the NF results came up with Error 40, not needed. The two factors cleared and displayed credit.[/QUOTE]

Having looked at the current server now, I can see that there are times when the disk subsystem really starts to get overwhelmed... it will start to page excessively and that results in SQL queries taking longer... if there are any writes involved, then the transaction log starts growing since it can't keep up, and everything else on the system starts to crawl.

I don't know exactly what kinds of things can trigger those episodes, but it is interesting to see the cascade effect in action.

The replacement system has much faster and more disks. More memory and 64-bit helps too because I think the real problem right now is the memory crunch from the large SQL dataset. It could possibly be helped by limiting SQL to 1 GB of the 2 GB total... the overall system could be more responsive in general and not page so much, but SQL does work better the more memory it has. I just wonder how much it really helps to say SQL can use 1GB or nearly 2GB when the database is in the dozens of GB in size.

I'd look at that angle more, reducing the SQL memory allocations, but hopefully that old server's days are numbered.

I'm not as available this coming week for testing but it's set up enough that George is doing more functionality tests... so far I've had v4 and v5 clients connect and get/check-in results and I think all of the website stuff is working. There were a few (minor, I think) PHP incompatibilities with the upgrade from 5.2 to 5.5 along the way but those would have needed fixing at some point anyway, so that's good.

In summary, better things are coming. :smile:

:tu: Good work! Eagerly waiting...

[QUOTE=Madpoo;380156]The replacement system has much faster and more disks. More memory and 64-bit helps too because I think the real problem right now is the memory crunch from the large SQL dataset. It could possibly be helped by limiting SQL to 1 GB of the 2 GB total... the overall system could be more responsive in general and not page so much, but SQL does work better the more memory it has. I just wonder how much it really helps to say SQL can use 1GB or nearly 2GB when the database is in the dozens of GB in size.[/QUOTE]

I have no experience with MSSQL, but in general, databases can more efficiently manage memory with larger internal caches than relying on an OS file system cache because they have additional insight into the data the OS lacks. If you reduce the memory allocated to MSSQL, the OS will use more memory to cache files recently written to, which is pointless if those files are also cached in MSSQL, and MSSQL will end up doing more disk reads as its caches are smaller.

Running a separate virtual machine for the database server is a good way to avoid having other processes page the database memory out. I would certainly do it.