Done. Will do 599_73 while C147 is still not ready. (trial filtering was run. Will wait for 1.7Gb to repeat.)

I get a feeling that there will be enough time to clear out one more - 1973,61-.

[QUOTE=RichD;295839]Reserving 593_73_minus1.[/QUOTE]

Nice split = p92 * p102.
Posted to factordb.

[CODE]p92 = 11226793024049045478341970579587061955572181740395462442754153008567825283410722235423405791
p102 = 505446252037436177637348831932098799804838929390221827325265159633328257769590552772209262900203315357[/CODE]

Heading out of town for nearly a week. Afraid to take another in fear it may not be done before I depart. Still plenty of variety for others at:
[url]http://boinc.unsads.com/rsals/crunching.php[/url]

1973,61- is not ready
 

It is undersieved (27-bit is bad for this size! [B]4M[/B] out of 15M relations were redundant and 11M are not producing a matrix.) Sieve some more, in a separate folder, and I'll be happy to pick up extra relations (3-4M more, because half of them will be redundant.)

I'll do 1627_67_minus1 instead.

[QUOTE=Batalov;295860]It is undersieved (27-bit is bad for this size! [B]4M[/B] out of 15M relations were redundant and 11M are not producing a matrix.) Sieve some more, in a separate folder, and I'll be happy to pick up extra relations (3-4M more, because half of them will be redundant.)
[/QUOTE]
The analysis of relations' specialqs shows that if you sieve above 32M (where this project stopped) you are going to expect on average only 1M new non-redundant relations per every 4M range. So I recommend sieving at least in the 32-38(better 40)M range.

[QUOTE=Batalov;295860]I'll do 1627_67_minus1 instead.[/QUOTE]
557,73- is done.
599,73- is done.
1627,67- in the morgen...ning. (ETA 8am)
...and C147 will be really ready then. :-) Morgen, morgen, nur nicht heute.

I'll take 1567_67_minus1.

EDIT: Also taking 541_79_minus1.

[QUOTE=Mathew;295731]I would like to reserve:

2460029275585695241_13_minus1 and
84969569171_19_minus1[/QUOTE]


2460029275585695241_13_minus1 is complete
[CODE]prp61 factor: 5974550413463052510945010516920654347494562183911588447658987
prp108 factor: 838760100216405611492729595346369900177894230557730608464794410948745799635579141419587473690381046453902391[/CODE]84969569171_19_minus1:
Log file states needs at least 1M more relations

I have updated the reservations, terminations, and expanded the range for 84969569171_19_minus1. Thanks :smile:

1627_67_minus1 is done (that should help a bit with the disk space), and C147 seems ready - I am finishing it now.
I'll finish 1973_61_minus1 when it's done upping.

I would suggest adding a [URL="http://ggnfs.svn.sourceforge.net/viewvc/ggnfs/trunk/contrib/remdups/"]remdups[/URL] server side run in the rsals_data/ folders (triggered by 'all jobs received'; and/or once manually on the gradfathered projects).

Something like (where $i is the root name of the subproject)
[CODE]gzip -dcfq $i.dat.gz |remdups4 222 |gzip > $i.rmdup.dat.gz[/CODE]
(you can redirect stderr into a report file, too)
This will save quite a bit on file transfer times.
It will also help to recognize the undersieved projects better.