Dropping 138738 (2^4 * 7^2 * 17 * 31 * ECMed C124)
Dropping 171552 (2^2 * 3^2 * 7, ECMed C128)

Dropping 440520 (2^5*3, ECMed C142)

Reserving 953172

Dropping 115440, 115596

Taking 103656, 171888

Taking 637032

Dropping 100656 (2^2*7^2, ECMed C121)
Dropping 199002 (2^5*3^2, ECMed C125)

Releasing 414468, 462920, 471504, 498360, 499080

I'll take 499080.

Dropping 138960 (2^4*31, ECMed C121)

Releasing 132600, 483282

Reserving 312330

Dropping 920064 (141 digits, 2^2*7, ECMed C136)

Dropping 156688 (2^2*5*7, ECMed C129)

Dropping 756630 (2*3*5*C146); have run 20k @ 1e6 on the C146 but it would need more ECM

Reserving 800922
Dropping 953172

Dropping 312330
Reserving 963342

Releasing 998850 (141 fully ecm-ed)

Reserving 239520
Dropping 963342

Dropping 806472 (size: 144, ECMed C136 cofactor)
Dropping 828600 (size: 117, ECMed C117 cofactor)

Dropping 807834 (2^3*3, ECMed C122)

Dropping 156174 (2^2*7, ECMed C123)

There is now no sequence less then a size of 122, which isn't reserved. So I start reserving sequences with size of 122 now and run them until a size of 130 (or termination).

[QUOTE=yoyo;414332]There is now no sequence less then a size of 122, which isn't reserved. So I start reserving sequences with size of 122 now and run them until a size of 130 (or termination).[/QUOTE]
(technically this is false :razz:, 319860 is at 41 digits and not reserved, but this sequence seems it is broken in the data base at 118 digits)
([URL="http://factordb.com/sequences.php?se=1&aq=2825523558447041736665230216235917892232717165769067317116537832686621082273062400083298623866666431871912457614030538&action=last20"]link to the continuation[/URL] of it)

Reserving 303996

[QUOTE=LaurV;414390]319860 is at 41 digits[/QUOTE]
121 digits :redface:
don't know how 41 got in :blush:

[QUOTE=LaurV;414390](technically this is false :razz:, 319860 is at 41 digits and not reserved, but this sequence seems it is broken in the data base at 118 digits)
([URL="http://factordb.com/sequences.php?se=1&aq=2825523558447041736665230216235917892232717165769067317116537832686621082273062400083298623866666431871912457614030538&action=last20"]link to the continuation[/URL] of it)[/QUOTE]

Ok, Ok, I'll take this also :)

@LaurV: you reserved the number by accident please drop it so yoyo can reserve it again

@yoyo: please reserve the number here because the reservations script can't handle broken sequences in your ali.txt.all file

[CODE]10:32:02 Unknown line from http://yafu.myfirewall.org/yafu/download/ali/ali.txt.all: 2825523558447041736665230216235917892232717165769067317116537832686621082273062400083298623866666431871912457614030538[/CODE]

Unreserving 319860

Unreserving 2825523558447041736665230216235917892232717165769067317116537832686621082273062400083298623866666431871912457614030538

:razz:

(Ha! did the script got upset by a line in my former post starting with "t"? I was afraid about that, but I thought it was fixed, and only when the full words like taking/reserving/dropping/unreserving are used, action is taken...)

reserving 319860

reserving 2825523558447041736665230216235917892232717165769067317116537832686621082273062400083298623866666431871912457614030538

You were using the number and the word "reserved" in the same line and that got picked up by the script (I think).

A bit further explanation: broken sequences are shown in the table with the correct size, index, known factors and everything else as if it was not broken. Only the links behind sequence and index point to the broken sequence and not the continuation. This can be reached through the links to the continuations on the top of the table.

Dropping 114408 (2^2*5*7, ECMed C126)

Dropping 637032 (2^3*3, ECMed C129)

Taking 352440 558600 889800 897930

Reserving 71028
Releasing 239520 (2^3*3^2*5, ECMed C131)

I have now much more user in yafu@home, so I have more then 900 Sequences reserved.
Maybe I will reserve more :)

yoyo

Taking 628656

Dropping 638766 (2^6*127, ECMed C139)

Dropping 135294.
Dropping 960132 (2401 lines were added).

Dropping 71028 (2^7*3, ECMed C121)
Taking 306390

Taking 263424

Taking 68880

Dropping 127896 (2 * 3^2 * 167; C143, has survived 20k@1e6 ECM)

[QUOTE=yoyo;415068]I have now much more user in yafu@home, so I have more then 900 Sequences reserved.
Maybe I will reserve more :)

yoyo[/QUOTE]

I can tell no one with the right privileges has tried running the script recently. I just got this error while testing:

[code]18:00:53 Wrote 2063 seqs
18:00:53 Error: 704 seqs couldn't fit into the posts
[/code]

We need another ~3 posts to fit all your reservations!

[QUOTE=Dubslow;415981]We need another ~3 posts to fit all your reservations!
Disclaimer: this is not a complaint! [/QUOTE]
Fixed that for you :razz:

[QUOTE=LaurV;415989]Fixed that for you :razz:[/QUOTE]

:smile:

Dropping 306390 (2^3*3*5^3, ECMed C116)
Taking 862728

Reserving 243102 542040 292788 688266 727596 841170 527694

Dropping 68880
Reserving 964700

yoyo@home just reserved over 1000 sequences. To fit them in I had to add 3 more posts. Anything that reads the first few posts will need to be updated. The new post ids are (165249, 397318, 397319, 397320, 397912,416583,416585,416586).

Dropping 295398
Taking 620826

Releasing 243102 542040

[QUOTE=henryzz;416587]yoyo@home just reserved over 1000 sequences.[/QUOTE]

There were many hosts requesting new work :D.

[QUOTE=yoyo;416739]There were many hosts requesting new work :D.[/QUOTE]

Warning if you think we will go beyond the size of the posts would be useful.

[QUOTE=henryzz;416587]yoyo@home just reserved over 1000 sequences. To fit them in I had to add 3 more posts. Anything that reads the first few posts will need to be updated. The new post ids are (165249, 397318, 397319, 397320, 397912,416583,416585,416586).[/QUOTE]

Whoops confused the script with this one.

[QUOTE=henryzz;416749]Warning if you think we will go beyond the size of the posts would be useful.[/QUOTE]

I think he did warn us (post 1191!) :razz: but no one was updating the head post back then...

[QUOTE=henryzz;416754]Whoops confused the script with this one.[/QUOTE]

How do you mean? Something I need to fix?

[QUOTE=Dubslow;416761]I think he did warn us (post 1191!) :razz: but no one was updating the head post back then...



How do you mean? Something I need to fix?[/QUOTE]

Just me adding sequences that don't exist. It didn't actually add them although they made it into the reason for editing.

Taking 665142.

Dropping 964700
Taking 559176

Releasing 292788 688266 841170

Taking 226092.

Releasing 527694 727596

Reserving 434760!

[QUOTE=Dubslow;417625]Here's an idea for a new subproject: the "standard" D5 is $2^5\cdot3\cdot7$ with class 0, but in fact $\sigma(2^6-1) = 3^2 \cdot 7$, so if a sequence mutates to $2^5 \cdot 3^2 \cdot 7$, then the $3^2$ is guaranteed to stay, so that the guide has class 2. We could target these for the subproject.[/QUOTE]
As far as I can tell there are 7 of them.
reserving one of them 696582

Dropping 434760

[QUOTE=henryzz;417736]As far as I can tell there are 7 of them.
reserving one of them 696582[/QUOTE]
Strike 1
After rising 8 digits it is now on 2^7*3^2*5.
It is now stuck on a c128 with a full t40
releasing 696582

Looking at it now I wonder where I got the number 7 from there are many more.

reserving 888144

Dropping 213486 628656

Dropping 665142 and 226092.

Since sieving at the c163 of 30450:808 took a while, I would like to get some help on optimizing the parameters.

Thank you in advance.

PS: The siever was gnfs-lasieve4i15e

Alfred

[QUOTE=Alfred;418116]Since sieving at the c163 of 30450:808 took a while, I would like to get some help on optimizing the parameters.
[/QUOTE]
a. It is normal to "take a while", for a C163.
b. you can not "optimize the parameters" of a poly you already have (I didn't look into the files, but it seems to be a poly, from the extension of the file names). However, you may find a better poly, if you search longer.
c. you can request a poly (better or not than the one you already have, depends on your luck, you may have hit a very good poly already) in the "request polys" thread, here around. Some people have "dedicated" hardware and are able to get very good polys very fast. You just specify the number, and where it is coming from (like "C163 from aliquot xxxxx") and someone may take up the challenge to find the best poly. The "where it comes from" is necessary because we don't try to factor encryption keys for gaming sites, etc.

[QUOTE=LaurV;418162]
b. you can not "optimize the parameters" of a poly you already have (I didn't look into the files, but it seems to be a poly, from the extension of the file names). However, you may find a better poly, if you search longer.[/QUOTE]

:huh:

...uh, yeah you can. The siever, factor base bounds, large prime sizes, large prime counts, whatever those lambda things are... there's a whole bunch of things to tweak with a given polynomial.

[QUOTE=Alfred;418116]Since sieving at the c163 of 30450:808 took a while, I would like to get some help on optimizing the parameters.

Thank you in advance.

PS: The siever was gnfs-lasieve4i15e

Alfred[/QUOTE]
Alfred-
The .poly file does not list the E-score for a polynomial by default, but your msieve log file will list the score. If you could post that, I can help you determine how much of your "took a while" was due to an insufficient poly-search phase, and how much was due to parameters being suboptimal.

I've been posting recently about how a number this size is likely faster with lpbr and lpba at 32 rather than 31 when running with the 14e siever. Going up a siever rather than up a large-prime-bound (lpb) also results in improved yield, at the cost of higher time per relation (sec/rel). 15e/30 isn't that weird, but I think 15e/31 or 14e/32 are faster by something like 10-20% of project length.

I would have run this with 14e siever, lpbr/lpba at 32, mfbr/mfba at the usual 2*lbpr/lbpa (64, in my case, though 31 and 62 would be roughly equal in project-length, I think), and alim = rlim = something around 45 or 50M. I would sieve from q = 10M to something like 60/65M, and expect a matrix to build with the filtering flag of target_density=90 (or 84 or 96 or 100, but not 70 because the matrix is too big and takes too long to solve). Given use of 15e siever, 31/62 bounds is probly faster than 32/64.

I don't think the lambdas need be messed with for individual-sized projects; I use 2.6 also, though for a C166 I may try 3.6 for alambda to see what happens.

My current C165 has a poly score of 6.67e-13, and Gimarel posted a poly for my next C166 at 6.46e-13. Scores drop 12-15% per digit usually, so I think a C163 should have a score above 8.0e-13. If your poly has a score down in the 6e-13 range, your factorization had the difficulty of a C165/166 with a good poly, 20-40% tougher than it should have been.

How many raw relations did it take to build a matrix? (at what target-density did you have it build?) I've never run a 30-bit project for a number this big, curious how relations scales.

[QUOTE=Dubslow;418177]:huh:

...uh, yeah you can. The siever, factor base bounds, large prime sizes, large prime counts, whatever those lambda things are... there's a whole bunch of things to tweak with a given polynomial.[/QUOTE]

This. GNFS just works without worrying much about parameters for projects in the 130-140 digit length, while parameter choice can start to save useful time in the 140-150 digit length. I took to heart Jason's advice to "turn the knobs" on a handful of ~140 digit factorizations before trying something in the 150s, and then did 3 in the 150s before my current dabble in the 160s. An iffy parameter choice at 140 digits might take 35 hrs instead of 25, but it stinks when a C163 takes 6 quad-core-weeks instead of 4!

That really low alim Alfred has might be what caused it to "take a while." Skew is higher than I'd like, but I don't have a good idea of how that influences yield; I don't do poly searches with a1 under 10,000 to reduce the chance of a wonky poly that looks good on a quick test-sieve but yields lower than desired.

Alfred, can you also post what your yield was at a couple of different q's? Specifically, the number of relations found for a block of 10k or larger q, such as "at q = 10M, a 100k block of q yielded 240,000 relations."

[CODE]c. you can request a poly (better or not than the one you already have, depends on your luck, you may have hit a very good poly already) in the "request polys" thread, here around. Some people have "dedicated" hardware and are able to get very good polys very fast. You just specify the number, and where it is coming from (like "C163 from aliquot xxxxx") and someone may take up the challenge to find the best poly. The "where it comes from" is necessary because we don't try to factor encryption keys for gaming sites, etc.[/CODE]

@LaurV

This is a very time saving offering. Thank you.
My knowledge (in order to find good polynomials is poor) my hardware is very poor.

Alfred

@ VBCurtis

Thank you for your answer.

[QUOTE]The .poly file does not list the E-score for a polynomial by default, but your msieve log file will list the score. If you could post that, I can help you determine how much of your "took a while" was due to an insufficient poly-search phase, and how much was due to parameters being suboptimal.[/QUOTE]

Two log files are attached.
None of these files is the complete log file - I've lost it.
But I think that I needed ~ 88 M relations (with duplicates).

[QUOTE]I've been posting recently about how a number this size is likely faster with lpbr and lpba at 32 rather than 31 when running with the 14e siever. Going up a siever rather than up a large-prime-bound (lpb) also results in improved yield, at the cost of higher time per relation (sec/rel). 15e/30 isn't that weird, but I think 15e/31 or 14e/32 are faster by something like 10-20% of project length.[/QUOTE]

I sieved a short q-range with the 14e and the same poly-file as for the 15e - not optimally.
Due to your advice the next time I can use better parameters.

[QUOTE]How many raw relations did it take to build a matrix? (at what target-density did you have it build?) I've never run a 30-bit project for a number this big, curious how relations scales.[/QUOTE]

I needed nearly 88 M raw relations to build a matrix with target-density 70.

[QUOTE]Originally posted by VBCurtis

Alfred, can you also post what your yield was at a couple of different q's? Specifically, the number of relations found for a block of 10k or larger q, such as "at q = 10M, a 100k block of q yielded 240,000 relations."[/QUOTE]


I changed the parameters to values you suggested:

rlim: staying 41500000
alim: from 21049999 to 41500000
lpbr: from 30 to 31
lpba: from 30 to 31
mfbr: from 30 to 62
mfba: from 30 to 62
rlambda: staying 2.6
alambda: staying 2.6

Testing these parameters with the 15e siever

with "gnfs-lasieve4i15e -R -v -f 30000000 -c 10000 -o 30450.out -a 30450.poly"

I get ~ 0.0543 sec/rel, yielding more than 56k rel.

My bad choice lead to a doubling of the sieveing time.

The next time I'll ask before starting the sieve job.

Alfred-
No, it's not a doubling of the project time, because the number of relations needed to build a matrix jumps by approximately 75% for each step of lpba/lpbr you go up. You needed 88M raw relations (raw = including duplicates) for 30LP; I believe you would need 150 to 155M for 31LP, but the relations come twice as quickly. So the time savings for my suggested parameters might save you 13-15% of time (1.75x as many relations, divided by 2x speed = 0.87ish). I put a range, because we don't know precisely how many relations will be required to build a matrix.

The score I requested is the "combined" number at the end of the poly in the log. 9.4e-13 is not a bad poly.

The siever does not process q less than alim, so you'll see a message "reducing alim to 29999999" for the test-sieve line you wrote with q = 30m, This is not a permanent change; as q rises, the siever's treatment of alim also rises (though it resets only each time it is called, so if you sieved say a 5M block of q for a week, alim remains fixed during that time).

Your yield with my params is 5.6 (56000 rels divided by -c of 10000), which is pretty high. That suggests it was 2.6 to 2.8 with your parameters, which is well within "reasonable" range. I don't think your choices were very bad, a C163 just takes a while ("a" in LaurV's response). Yields under 2.0 generally mean you should change parameters and start over, but 2.7 does *not* tell you that.
If your test-sieve is representative of the whole region, I think my parameter suggestions would lead to a q-range of (155M / 5.6) = 27M or 28M; say,q from 25M to 53M. If I'm estimating correctly, you needed (88M/2.7) = 32M or 33M range of special q. Again, not a huge difference, nor one to suggest you should regret your choices.

@VBCurtis

My sieving range was q=21M to 56M.

I've learned a lot.

Thank you for your very detailed answer.

You're welcome, sir. I see threads like this as a chance for me to put into words what I think I've learned from 2 years of knob-turning (tinkering with parameters and the factmsieve.py script). I enjoy doing so, not least because quite often one of the true experts corrects my beliefs, and everyone gains.

One more idea for you: I found better results by starting the sieve region at alim/3 rather than alim/2 (the default in the script). This change reduces the frequency of going up into q's where yield (and sec/rel) fall off badly. On some factorizations it makes no difference, but on poor-yielding polys where the sieve has to go well above alim, the range from alim/3 to alim/2 is usually more fertile than the range from (for instance) 1.3*alim to 1.5*alim. In your case, supposing alim = rlim = 42M, I would aim for 14M to 49M rather than 21M to 56M. I think 14M to 21M is more efficient than 49M to 56M, but this varies *a lot* from job to job.

Releasing 236840 856530 933564 570996 93000

Releasing 761516 832314

Taking 541458

Taking 721386
Releasing 862728

Taking 59430
Releasing 559176

Releasing 701784 693120 913920 282168 27570

Taking 621036
Releasing 800922 303996

Dropping 541458

Taking 524814

Dropping 524814

Taking 81192

Releasing 416250 803598

Releasing 727596

Releasing 263424
Taking 956840

Dropping 246648 465750

Releasing 822432 897960

Reserving 329490.

Reserving 70884

Dropping 81192

Taking 790308 920976 518628 435420 337860 977160 127848 456372 362880 379272 136500 246708 958704 898752 211812 417726 to 130 digits

[QUOTE=Dubslow;420057]Dropping 81192

Taking 790308 920976 518628 435420 337860 977160 127848 456372 362880 379272 136500 246708 958704 898752 211812 417726 to 130 digits[/QUOTE]

According to our frequently updated reservation page: [url]https://www.rechenkraft.net/aliquot/AllSeq.html[/url]

[QUOTE]
Warning: seq 920976 is owned by yoyo@home but is trying to be reserved by Dubslow!
Warning: seq 337860 is owned by Happy5214 but is trying to be reserved by Dubslow!
Warning: seq 211812 is owned by yoyo@home but is trying to be reserved by Dubslow![/QUOTE]

[QUOTE=yoyo;420064]According to our frequently updated reservation page: [url]https://www.rechenkraft.net/aliquot/AllSeq.html[/url][/QUOTE]

Whoops! I used the same tools to scrape the [URL="http://mersenneforum.org/showpost.php?p=417625&postcount=1219"]sequences of interest[/URL], and completely forgot to check for reservations :smile: I'll not step on your toes.

dropping 888144
[URL="http://factordb.com/sequences.php?se=1&aq=888144&action=last20&fr=0&to=100"]888144[/URL] currently 2^5*3^2*7*13 which seems very stable. I have ecmed the c144 to around t44.
I would love to see this one picked up and continued as I would love to see it lose this guide. It is rising quickly if anyone wants to set a PB for largest sequence. This is the largest I have taken a sequence.

reserving 672834 to replace it