[QUOTE=Madpoo;380865]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.

[snip][/QUOTE]

Just manually checked in a 191kb results file, containing 24 factors and 1978 no factor results lines.

Took about 30 seconds to process :tu:

[QUOTE=Gordon;380898]Just manually checked in a 191kb results file, containing 24 factors and 1978 no factor results lines.

Took about 30 seconds to process :tu:[/QUOTE]

It's using YAFU now to check the "factor found" results instead of Msieve. I don't have any stats at all on how the old msieve routine did, except I know it was a 32-bit DLL and ran in SQL as an extended procedure. YAFU on the other hand is 64-bit which probably helps quite a bit.

For fun I took the last 100 factor-found results and timed how long it took YAFU to run through them. 16.44 seconds first run, 15.52 seconds on the next run, and that's with OS overhead of calling an EXE for each number, sequentially. CPU usage during that only climbed another 5-8%.

Like I said, I don't know how that compares to the old system, but I'm just throwing that out there.

[QUOTE=Madpoo;380951]Like I said, I don't know how that compares to the old system, but I'm just throwing that out there.[/QUOTE]

:bow:

[QUOTE=Madpoo;380951]It's using YAFU now to check the "factor found" results instead of Msieve. I don't have any stats at all on how the old msieve routine did, except I know it was a 32-bit DLL and ran in SQL as an extended procedure. YAFU on the other hand is 64-bit which probably helps quite a bit.

For fun I took the last 100 factor-found results and timed how long it took YAFU to run through them. 16.44 seconds first run, 15.52 seconds on the next run, and that's with OS overhead of calling an EXE for each number, sequentially. CPU usage during that only climbed another 5-8%.

Like I said, I don't know how that compares to the old system, but I'm just throwing that out there.[/QUOTE]

One more little test to see how it handles large #'s, I ran YAFU on the 1000 largest factors. CPU usage averaged 20% the whole time and it finished in 2 minutes, 55.67 seconds. Pretty good... there are some big #'s in there, like the one for exponent 1061:
46817226351072265620777670675006972301618979214252832875068976303839400413682313921168154465151768472420980044715745858522803980473207943564433

I'm sure a GPU could blow this "little" server away, but it's definitely up to the task of handling the factor checking involved when results come in. Even in a worst case where someone checks in 1000 really large factor-found results, hey, under 3 minutes. :)

The issue I noted in post #504 still exists.

My manual results for two double checks on 33464617 and 33464659 are in limbo according to the exponent status page: [URL="http://www.mersenne.org/report_exponent/default.php?exp_lo=33464617&exp_hi=33464659"]http://www.mersenne.org/report_exponent/default.php?exp_lo=33464617&exp_hi=33464659[/URL].

I tried resubmitting via manual results and was advised: "Error code: 40, error text: This computer has already sent in this LL result."

They do not show up in my results. Would someone be able to tweak these two results so they are recognized by the server? Thanks!

[QUOTE=Madpoo;380979]One more little test to see how it handles large #'s, I ran YAFU on the 1000 largest factors. CPU usage averaged 20% the whole time and it finished in 2 minutes, 55.67 seconds. Pretty good... there are some big #'s in there, like the one for exponent 1061:
46817226351072265620777670675006972301618979214252832875068976303839400413682313921168154465151768472420980044715745858522803980473207943564433

I'm sure a GPU could blow this "little" server away, but it's definitely up to the task of handling the factor checking involved when results come in. Even in a worst case where someone checks in 1000 really large factor-found results, hey, under 3 minutes. :)[/QUOTE]

It occurs to me that both PARI and YAFU will "factor" a prime # very quickly. I was assuming that when clients check in a "factor found" result, it's a prime factor, but I understand that's not really the case.

True enough, YAFU will take longer to factor a large composite number.

Case in point, I wondered if PARI would be any faster than YAFU on the new server since James had provided some PHP code that would do it either way.

I hammered out a 118 digit number and set both of them to work, timing each.

PARI = 50 minutes, 12.94 seconds
YAFU = 3 minutes, 24.82 seconds

So YAFU is the clear winner on this hardware at least, and for a number that large. PARI was faster to check a prime factor by 3 or 4 times, but then it's only taking 1.5 seconds maybe to check a really large prime number to see if it's prime or not.

Now I want to go through the results that actually come in and see how long YAFU might take on what's being reported, not the prime factors that wind up in the database after any composite factors are checked.

It's not merely an academic exercise... It would be a good benchmark to see how many incoming "factor found" results the server can actually handle at any given time, if I have an idea of the throughput. Now that disk isn't so much the bottleneck, future-proofing the server means looking at other systems like CPU.

Anyone have any good info on what factoring program is generally the fastest at this kind of work? I've tried YAFU and PARI but I haven't tried an msieve executable, so that might be worth a go, since it was using an msieve library previously, albeit an old and 32-bit version.

The server tries to factor all submitted factors?

There's two issues at stake when a new factor is submitted:
1) Does the submitted factor actually divide the exponent it is claimed to.
2) Is the submitted factor prime or composite.

The first bit it simple and quick, it's just a single check for does this-divide-that.

The second part is more complex and yes, the server has to factor all submitted factors to either verify that they're prime, or split them up into their prime components and process each component factor.

Why does it matter if the factor is a prime factor or a composite factor?

Only prime factors should be recorded, for clarity, simplicity and sanity of the database. If a composite factor is submitted it should be broken down and only the prime factors recorded.

[QUOTE=James Heinrich;381025]Only prime factors should be recorded, for clarity, simplicity and sanity of the database. If a composite factor is submitted it should be broken down and only the prime factors recorded.[/QUOTE]

Just wondering... Is this done serially (batched), or during the submission process? It would seem to me that the former would be best, as it wouldn't hold up the submitter, and would prevent the possibility that two or more checks are running in parallel.