[QUOTE=RichD;296656]I'll take 59999_224 for post-processing.[/QUOTE]

... has the following 3-way split.

[CODE]prp57 = 105116020583942511342885176898761927907189004109190530401
prp76 = 1426059807243826084017245666438603503793360364869025030507580931023978750559
prp92 = 93084237127002259679956520230759468590779235272795409083718349071592458482718710155281572227[/CODE]

[QUOTE=RichD;296672]I'll take 1303_73_minus1 next ...[/QUOTE]

Splits as:

[CODE]prp53 = 11275026896015715396266211602906023027070936444681521
prp173 = 16757675495098280254007897396672938591079769333566901478701118134737798224381154428839630271792313539352990289355292138440071159542725363152895704058837312540829939629219441[/CODE]

I'll take 599_79_minus1 next.

Thanks, I have updated the pages :smile:
With quite a bit of luck, ECM could have found the p53 in 1303^73-1, but a p53 is not an ECM miss for a number of that size.

3281533_37_minus1 is proving to be difficult to sieve, though the value of the SNFS difficulty is not [i]that[/i] high...

Lionel, 1753_71_minus1 is already done long time ago. You can clean it from the current jobs page.

[QUOTE=debrouxl;296904]

3281533_37_minus1 is proving to be difficult to sieve, though the value of the SNFS difficulty is not [I]that[/I] high...[/QUOTE]

The poly you used has a high A6 coefficient, I get the same poly as you. Is there away to reduce it? Xilman taught me to reduce the high coefficient but that was on the CGW case.

[code]SKEW 0.0820327373947421
A6 3281533
A5
A4
A3
A2
A1
A0 -1
R1 1
R0 -1248707315437094191905435404583477994969
[/code]

I'll take 619_79_minus1 next - which is mostly downloaded.

The two test cases I processed early went without a flaw. Batalov suggestion to remove dups before posting the .dat file makes the download time quicker and appears to speed up the post-processing a tad.

It would be nice if you could implement his suggestion on an ongoing basis, if possible.

[QUOTE=RichD;296949]and appears to speed up the post-processing a tad.

[/QUOTE]

Are you sure? I think the filtering phase reduces by a few minutes ( 2-3 mins) depending on your processing speed. The LA time phase remains the same.
Just to be sure can you post your 1303_73_minus1 msieve log file? Thank you.

[QUOTE=pinhodecarlos;296958]Are you sure? I think the filtering phase reduces by a few minutes ( 2-3 mins) depending on your processing speed. The LA time phase remains the same.
Just to be sure can you post your 1303_73_minus1 msieve log file? Thank you.[/QUOTE]

I'm sure all the savings are in -nc1 with the heavy disk I/O. So I agree with your statements.

A tad (in U.S. English) usually means less than a little bit. :smile:

Attached is the log file. I ran it in three parts incase there were problems (which there were none).
Cheers

[QUOTE=RichD;296881]I'll take 599_79_minus1 next.[/QUOTE]

... which splits nicely as:

[CODE]prp91 = 5925620876990062909632261750298082111726899319981907562549423441377774872384822693608927781
prp95 = 15211720737624860843140612257476146694052577488310736413025740567399088898966410515472918662907[/CODE]

My comments are placed here, based upon remarks in another thread, but thought it would be appropriate to discuss here.

It appears there is a void between RSALS and NFS@Home. Will there ever be a RSALS15 project, using lasieve4I15e? I hesitate to use RSALS5 because it may be later construed as using the lasieve5I siever which I believe is in the making.

The 15e can reach higher bounds put may require smaller work units.
(Also 64-bit would be of much improvement.)

[quote]It appears there is a void between RSALS and NFS@Home.[/quote]
Yup, because we don't tackle the same kind of numbers.

[quote]Will there ever be a RSALS15 project, using lasieve4I15e?
The 15e can reach higher bounds put may require smaller work units.
(Also 64-bit would be of much improvement.)[/quote]
In fact, the more logical thing to do would be to merge RSALS to NFS@Home, because NFS@Home already has a 64-bit-capable 14e siever and a more reliable server :smile: