You're fully right in principle :smile:

We're however reducing that "multiple undersieved integers" effect, which has already burned us in the past (though we're not quite as close to the limit as we were a month ago, thanks to the OddPerfect people) through two factors used complementarily:
* the scripts treat older integers before newer integers, i.e. WUs for older integers get queued before WUs for newer integers;
* for now, the scripts don't automatically increase the end of the range in case there aren't enough relations, they just generate WUs until they reach the value that we humans have specified. So if we let the end of the range well short of what it will need to be in the end (we currently do for C242_125_86, for example), that integer will effectively have lower priority than the other integers.


As shown by [url]http://boinc.unsads.com/rsals/crunching.php[/url] (I've just updated it), the following integers are both ready for post-processing and unreserved:
60001_247 (31-bit primes) - ~15e9 bytes of compressed raw sieving data
89999_243 (31-bit primes) - ~15e9 bytes of compressed raw sieving data
13333_247 (30-bit-primes) - ~9e9 bytes of compressed raw sieving data
13_197_minus1 (29-bit primes) - some results are still coming in, but there's already enough data for post-processing, I believe

How much memory is required to post-process the 29-bit tasks currently on the list? I have a Core 2 Duo with 2 GB of RAM that, given the current backlog, might be able to help out if any of the jobs can fit within <1.5 GB of memory (since I use this computer actively and a chunk of the RAM is taken by Windows and various applications).

I have an eight-core 32GB Opteron box available, on which I would be prepared to post-process any two numbers desired. Is this a useful offer? mail [email]tom@womack.net[/email] with details if you want to take it up.

Thanks both of you for the offers, they're definitely useful :smile:

I've post-processed several 29-bit-primes tasks in the past on two Core 2 Duos, and I saw that the linear algebra phase often fits in 1.5 GB of RAM (but can impact normal usage of the computer). More troublesome is the filtering phase, whose memory requirements easily peak between 2.5 and 3 GB.

I'll contact both of you by e-mail.

Running 89999_243 and 60001_247:

[code]
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2050 nfsslave 20 0 4731m 4.6g 1064 R 400 14.5 352:08.77 msieve
2028 nfsslave 20 0 4875m 4.7g 1064 R 399 15.0 307:02.79 msieve
[/code]

[code]
89999_243
Sun May 9 15:30:25 2010 matrix is 13782154 x 13782379 (3951.9 MB) with weight 959447309 (69.61/col)
Sun May 9 15:30:25 2010 sparse part has weight 898135569 (65.17/col)
60001_247
Sun May 9 15:13:18 2010 matrix is 13383898 x 13384124 (3837.9 MB) with weight 943193442 (70.47/col)
Sun May 9 15:13:18 2010 sparse part has weight 872232659 (65.17/col)
[/code]

Looks like running two jobs on one two-socket machine is too much load (getting ETA of 1200 hours for one job and 750 for the other), will swap one over when the machine whose system-USBstick broke on Thursday is back up tomorrow night. Let's say ETA mid-June.

a few words about ECM
 

Dear friends at RSALS project,

I wanted to bring to your attention that you apparently do not do enough ECM for your projects. I understand that this is your spare computer time and you can surely do it in any way you want, but still I hope that you will agree that it would have been beneficial for your project to be able to do two factorizations using the same amount of time that was used for one like 10[SUP]250[/SUP]+3. (It should have been ECM'd to at least 55-digits level, which is 2/9th of the size - a standard conservative level, and then a gnfs-151 job would have taken 1/15th of the time of snfs-252.)

ECM tasks that could be needed for this pipeline are also easily BOINC'd if they aren't already. Or alternatively you can build a better collaboration with yoyo @ home.

Good luck, and I hope that you will not find offense in my advice,

--Serge

Hi Serge,

Your input is seen as valuable (it's not offensive at all), and indeed, we do realize that "10003_250" was a double ECM miss :no:

All of the remaining near-repdigit-related tasks have the potential to be, to some extent, ECM misses, since they were pushed to only t45 before I fed the RSALS grid with them... I was crossing fingers that we'd see only single ECM misses (since a single factor in the 45-60 digits range wouldn't have changed the difficulty of the factorization, SNFS would have remained easier than GNFS)... failed.

Since those tasks were sieved, I have however raised the bar for ECM work :smile:
* XYYXF: I have pushed C242_125_86 a bit beyond t50 myself (nearly 8000 curves at B1=43e6 + several hundreds of curves at B1=11e7), and Andrey of XYYXF has pushed the two RSALS reservations to t50 through yoyo@home (completing one factorization by p49 * p182);
* OddPerfect: William Lipp provides us with SNFS 220-250 tasks that have been pushed to t50;
* Aliquot: "C158_660_857" has been pushed to t45 (~2/7 of the GNFS difficulty) by the people at LORIA.

Therefore, in the future, RSALS shouldn't make ECM misses as significant as 10003_250 was :smile:


Thanks,
Lionel.

Automated Webbery is far from my strong suit, but I think

[url]http://www.fivemack.org/gnfs-completion/progress.html[/url]

will show the progress of the two RSALS jobs. Updates every ten minutes.

[QUOTE=debrouxl;214499]... I was crossing fingers that we'd see only single ECM misses (since a single factor in the 45-60 digits range wouldn't have changed the difficulty of the factorization, SNFS would have remained easier than GNFS)... failed.[/QUOTE]Unless that single factor would have left a prime cofactor of course.

Indeed :smile:

[quote=fivemack;214514]Automated Webbery is far from my strong suit, but I think

[URL]http://www.fivemack.org/gnfs-completion/progress.html[/URL]

will show the progress of the two RSALS jobs. Updates every ten minutes.[/quote]
Hmm, I just get "Internet Explorer cannot display this webpage". (Unless this is just because I'm attempting to load it at :02 after the hour, possibly while it's still attempting to do its 10-minute update?)