mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   NFS@Home (https://www.mersenneforum.org/forumdisplay.php?f=98)
-   -   BOINC NFS sieving - RSALS (https://www.mersenneforum.org/showthread.php?t=12458)

debrouxl 2010-06-28 19:12

[quote]No obvious reason why it should.[/quote]ACK, thanks. So I'll guess that it was bad luck, and make the grid sieve all 29-bit large primes tasks until 59-61M relations :smile:

[quote]I can expand on what "small" means in this context if there is interest.[/quote]The coefficients for all OddPerfect SNFS polynomials we used for sieving so far are below 1000 in absolute value. Is that what you mean ?

axn 2010-06-28 19:28

[QUOTE=debrouxl;220084]ACK, thanks. So I'll guess that it was bad luck, and make the grid sieve all 29-bit large primes tasks until 59-61M relations :smile:
[/QUOTE]
The aliquots where difficulty GNFS 15x, while 127_97 is a SNFS 204 (GNFS 14x). So you'll need less relations for the SNFS.

wblipp 2010-06-29 06:58

[QUOTE=xilman;220052]The only difference between SNFS and GNFS is that in the former it is possible to find polynomials with "small" coefficients. I can expand on what "small" means in this context if there is interest.[/QUOTE]

I'm interested. At present we are feeding RSALS with numbers that trivially form SNFS as x^6-a or a*x^n-1 with a < 1000. But over time the best remaining candidates will have larger values of a.

William

pinhodecarlos 2011-12-01 10:02

[url=http://boinc.unsads.com/rsals/crunching.php]So far RSALS completed more than 195 factorizations.[/url]

debrouxl 2011-12-15 20:49

Pace Nielsen wrote me that he won't have much time for post-processing in the next few weeks, so I'm looking for more post-processing power, because the server tends to be filling up more quickly than Carlos Pinho and I can post-process the larger datasets :smile:
(and yet, I used a small, slow server to post-process a couple very easy tasks)

At the moment, RSALS is sieving only numbers that have received ECM up to 2/9 of SNFS difficulty, so ECM misses are very unlikely, I promise :wink:


Two 31-bit LPs task are currently taking 14-15 GB each: 257_103_minus1 and 233_103_minus1. The .fb and .ini files for 257_103_minus1 are on the server, and the poly file for 233_103_minus1 is:
[code]# (233^103-1)/1404859428260046270768207699653557238344
# 233*x^6-1, x=233^17
n: 4898092643922188074955030879138316230299430966381687612064584001575030588411631845918439842464082225902287544857917712000787315914206488859933180116842709737704144152432068993642811371404377587816159292219
m: 17581286755278324467080452639806113780073
deg: 6
c6: 233
c0: -1
type: snfs
skew: 0.40312587982308
rlim: 81100000
alim: 81100000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.6
alambda: 2.6[/code]
I'll upload the 233_103_minus1 .fb and .ini files this week-end.

Beyond that, I need to compute the list of missing WUs for 20003_245, and queue what it takes to raise it above 200-210M raw relations.


Thanks in advance for the help :smile:

frmky 2011-12-15 22:41

[QUOTE=debrouxl;282332]The .fb and .ini files for 257_103_minus1 are on the server[/QUOTE]

Downloading them now.

pinhodecarlos 2011-12-15 22:42

Lionel,

Probably you already notice I didn't reserve numbers since 04 Dec because I had to shutdown all my processor power therefore count me also out for the next weeks as Pace.

Carlos Pinho

debrouxl 2011-12-16 07:43

Yup, I had noticed, Carlos :smile:

Thanks for taking 257_103_minus1, Greg.


Until I can upload them to the server, here are the files for 257_97_minus1 and 233_103_minus1:

257_97_minus1.fb:
[code]N 26191380487592321209014054853996203395265270062971535209335586780977511518059538680062648075083008357912962197986737707279317540665350728748558379627895375971654354663722751656036208051422073
SKEW 0.396592484004374
A6 257
A5
A4
A3
A2
A1
A0 -1
R1 1
R0 -362184594182720980613658216570962841601
FAMAX 67108863
FRMAX 67108863
SALPMAX 1073741824
SRLPMAX 1073741824[/code]

257_97_minus1.ini
[code]
26191380487592321209014054853996203395265270062971535209335586780977511518059538680062648075083008357912962197986737707279317540665350728748558379627895375971654354663722751656036208051422073[/code]

233_103_minus1.fb:
[code]N 4898092643922188074955030879138316230299430966381687612064584001575030588411631845918439842464082225902287544857917712000787315914206488859933180116842709737704144152432068993642811371404377587816159292219
SKEW 0.40312587982308
A6 233
A5
A4
A3
A2
A1
A0 -1
R1 1
R0 -17581286755278324467080452639806113780073
FAMAX 81100000
FRMAX 81100000
SALPMAX 2147483648
SRLPMAX 2147483648[/code]

233_103_minus1.ini:
[code]4898092643922188074955030879138316230299430966381687612064584001575030588411631845918439842464082225902287544857917712000787315914206488859933180116842709737704144152432068993642811371404377587816159292219[/code]

Mathew 2011-12-16 21:43

debrouxl,

I would like to reserve 257_97_minus1 (currently downloading).

fivemack 2011-12-16 23:14

Getting large numbers of duplicates is, in my experience, generally a sign that either the siever you're using or your large-prime bound is too small - looking through my archives, the duplication rates above 20% that I've seen are for running 29-bit large prime jobs with 14e on 150 to 155-digit GNFS numbers. However, even with the duplicates, they've run a little faster than 30-bit large prime jobs on nearby numbers.

debrouxl 2011-12-17 07:32

Reserved 259_97_minus1 for you, Mathew :smile:


All times are UTC. The time now is 09:53.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.