[QUOTE=debrouxl;495665]Alright, I raised the upper bound for C179_374xx231_19 to 300M.
The poly doesn't have a "type:" line, but since it has a "lss:" line, I'd expect it to have been sieved on the right side anyway.[/QUOTE]

Thanks. I wonder what happened to the "type:" line! It was in the original [url=https://www.mersenneforum.org/showpost.php?p=494206&postcount=1560]post[/url].

[QUOTE=RichD;494880]C200 from the OPN t600 file (for 14e).
[ a.k.a. Phi_19(Phi_3(Phi_3(Phi_3(612067)/3/4801)/3/43/9949)/3/41233)/15733/90791273/58231064341 ]
Sieve on algebraic side.
[CODE]n: 25503431421917993101321887118006938878378655964476437605074260560152721672529861314581467042556964110748403572526947437910470022455618855395879515986932272093603127760772643420867362459955421459731663
# 2246354414917^19-1, SNFS-235, sieve on algebraic side
lss: 0
skew: 0.0087
c6: 2246354414917
c0: -1
Y1: -1
Y0: 11335347337562584746201140717669233213
type: snfs
rlim: 134000000
alim: 268000000
lpbr: 31
lpba: 32
mfbr: 62
mfba: 94
rlambda: 2.6
alambda: 3.7[/CODE]Trial sieving 5K blocks.
[CODE] Q Yield
20M 9932
60M 6084
100M 5822
200M 5389
250M 4015
300M 4021
350M 4561[/CODE][/QUOTE]
Can somebody explain (in simple/layman terms) why these parameters are so different from the other OPN SNFS numbers?
(31-32bit hybrid)
mfba: 94? (not 2x lpba)
and high alambda 3.7
sieving on [U]algebraic[/U] side (I thought SNFS were mostly sieved on the rational side???)

:confused2:

[QUOTE=VictordeHolland;495779]Can somebody explain (in simple/layman terms) why these parameters are so different from the other OPN SNFS numbers?
(31-32bit hybrid)
mfba: 94? (not 2x lpba)
and high alambda 3.7
sieving on [U]algebraic[/U] side (I thought SNFS were mostly sieved on the rational side???) :confused2:[/QUOTE]
mfba 94 is just less than 3 * lpba, which tells you this poly file uses 3 large primes on the algebraic side for sieving. Similar to selecting a sextic rather than a quintic polynomial, there is a size of problem where 3 large primes on one side improves yield quite a lot while sieving as quickly (or, at larger sizes, quite a bit faster) as 2 large primes. ETA: My personal experience is that test-sieving 3LP vs 2LP should be tried starting around SNFS-250 and GNFS-175. 3LP isn't always faster, but on some problems it's a substantial improvement.
Lambda is chosen as 3.x when using 3 large primes, 2.x (or, rarely, 3.0) when using two large primes. So, once 3 LPs on a side were selected, alambda was chosen to match.
Note that 3 large primes on both sides isn't used until *much* larger problems (say, SNFS 310+ or GNFS 220+, perhaps larger- I don't have much experience up there!).

I'm not used to seeing lim's chosen larger on the sieving side than the other side; I'm curious about the test-sieving results on that one!

[QUOTE=VBCurtis;495809]mfba 94 is just less than 3 * lpba, which tells you this poly file uses 3 large primes on the algebraic side for sieving. Similar to selecting a sextic rather than a quintic polynomial, there is a size of problem where 3 large primes on one side improves yield quite a lot while sieving as quickly (or, at larger sizes, quite a bit faster) as 2 large primes. ETA: My personal experience is that test-sieving 3LP vs 2LP should be tried starting around SNFS-250 and GNFS-175. 3LP isn't always faster, but on some problems it's a substantial improvement.
Lambda is chosen as 3.x when using 3 large primes, 2.x (or, rarely, 3.0) when using two large primes. So, once 3 LPs on a side were selected, alambda was chosen to match.
Note that 3 large primes on both sides isn't used until *much* larger problems (say, SNFS 310+ or GNFS 220+, perhaps larger- I don't have much experience up there!).

I'm not used to seeing lim's chosen larger on the sieving side than the other side; I'm curious about the test-sieving results on that one![/QUOTE]
Thanks for satisfying my curiosity :bow:

[QUOTE=VictordeHolland;495779]Can somebody explain (in simple/layman terms) why these parameters are so different from the other OPN SNFS numbers?
(31-32bit hybrid)
mfba: 94? (not 2x lpba)
and high alambda 3.7
sieving on [U]algebraic[/U] side (I thought SNFS were mostly sieved on the rational side???)

:confused2:[/QUOTE]

[B]VBCurtis[/B] did a great job explaining the mechanics of the polynomial, let me see if I can explain the logic.

The OPN numbers are pretty much cookie cutters once you get a working polynomial. Each exponent would have a general form. For p^5-1 and p^7-1 you can divide out a p-1 to make a quartic or sextic. For p^11-1 and p^13-1 a degree halving technique is used to get a quintic or sextic. For p^17-1, p^19-1 and p^23-1 these are troublesome SNFS jobs because of the large coefficients. For sizes suitable for the 14e queue it is better to sieve on the algebraic side. Beginning with p^23-1 and up, these are more traditional SNFS jobs with smallish coefficients. But if the coefficients get too big (say, greater than 7-8 decimal digits) then the algebraic side should be considered. I think I had a large p^31-1 (or a p^29-1) on the -a side not too long ago.

The number you question is a SNFS-235. I had a recent (C179_374xx231_19 - SNFS-239) job that barely fit as a 31-bit job. For some reason the yield was not good at all for the SNFS-235 number. When I bumped it to a 32-bit job, it seemed to be an overkill wth yield above 3:1. To squeeze more yield one can expand the lim’s but that usually only adds about 10% more with a 30% or so penalty in relations time. Another option is to use 3LP on one side. (You can’t use 3LP on both side because GGNFS will barf.) This is more beneficial with OPN numbers. Occasionally the time per rel will slightly decrease but generally one can get a 10-20% bump in yield with only a small penalty in time.

So I decided on a hybrid. Most of my 32-bit post-processing jobs take 2-4 weeks while the 31-bit jobs are around 5-8 days. Split the difference, 2-2.5 weeks??

As [B]Batalov[/B] once said, “try test sieving, you may be missing out on all the fun.”

C206 from the OPN t600 file.
Sieve on ALGEBRAIC side.
[CODE]n: 211729082358149184616654442570096012275452733025471882338226429873172324982177451616911629080660858615779105540909697308361957755666817267484570213046930959867537205284848983532914754295909575808877341405213321228096584089683
# 30027973^31-1, difficulty: 232
lss: 0
c6: 30027973
c0: -1
Y1: -1
Y0: 24413502119045705366054121155817391093
skew: 0.0567
type: snfs
rlim: 134000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.6
alambda: 2.6[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
20M 11749
60M 10345
100M 10445
150M 9273[/CODE]

[QUOTE=RichD;495869]
So I decided on a hybrid. Most of my 32-bit post-processing jobs take 2-4 weeks while the 31-bit jobs are around 5-8 days. Split the difference, 2-2.5 weeks??[/QUOTE]

I think this is a fallacy; LA time scales with input difficulty and barely changes by LP choice. If you take a typical 31LP job and run it as a 32LP job, the matrix will be less than 10% bigger, and can even be smaller. Your 32LP jobs have taken longer because they're much tougher inputs, not because they're 32LP. Half our 14e jobs would sieve faster 1LP bigger, without altering matrix sizes much. Alas, that requires more disk space, so perhaps the current choices are best for the project even though not optimally efficient.

Yield 3.0 sounds quite nice, not overkill! I'm almost certain yield under 2.0 is a sign to go up an LP, while 2.5 to 3.5 is a sign of good parameter selection. This hybrid ended up with yield around 1.0, so something got lost between test-sieve and queue.

[QUOTE=VBCurtis;495883]I think this is a fallacy; LA time scales with input difficulty and barely changes by LP choice. If you take a typical 31LP job and run it as a 32LP job, the matrix will be less than 10% bigger, and can even be smaller. Your 32LP jobs have taken longer because they're much tougher inputs, not because they're 32LP. Half our 14e jobs would sieve faster 1LP bigger, without altering matrix sizes much. Alas, that requires more disk space, so perhaps the current choices are best for the project even though not optimally efficient.

Yield 3.0 sounds quite nice, not overkill! I'm almost certain yield under 2.0 is a sign to go up an LP, while 2.5 to 3.5 is a sign of good parameter selection. This hybrid ended up with yield around 1.0, so something got lost between test-sieve and queue.[/QUOTE]

You are probably correct. My latest job, C208_129_112, built a 23.5M matrix at TD=140 with ETA less than 600 hours.
[CODE]commencing 2-way merge
reduce to 58897286 relation sets and 38285767 unique ideals
commencing full merge
memory use: 3432.8 MB
found 25400232 cycles, need 23563967
weight of 23563967 cycles is about 3299522725 (140.02/cycle)
distribution of cycle lengths:
1 relations: 2474232
2 relations: 1235095
3 relations: 1227937
4 relations: 1234334
5 relations: 1274818
6 relations: 1283572
7 relations: 1292890
8 relations: 1281564
9 relations: 1263155
10+ relations: 10996370
heaviest cycle: 27 relations
commencing cycle optimization
start with 221581438 relations
pruned 14657964 relations
. . .
matrix is 23557761 x 23557961 (12244.6 MB) with weight 3470184645 (147.30/col)
sparse part has weight 2950713788 (125.25/col)
matrix starts at (0, 0)
matrix is 23557761 x 23557961 (12244.6 MB) with weight 3470184645 (147.30/col)
sparse part has weight 2950713788 (125.25/col)
saving the first 48 matrix rows for later
matrix includes 64 packed rows
matrix is 23557713 x 23557961 (11720.7 MB) with weight 3025470142 (128.43/col)
sparse part has weight 2836938274 (120.42/col)
using block size 8192 and superblock size 589824 for processor cache size 6144 kB
commencing Lanczos iteration (4 threads)
memory use: 11228.2 MB
linear algebra at 0.0%, ETA 598h46m[/CODE]

I believe you suggested a yield of 2:1 with an end point of no greater than two times lim, which I thought I followed. My bad.

[QUOTE=RichD;495886]
I believe you suggested a yield of 2:1 with an end point of no greater than two times lim, which I thought I followed. My bad.[/QUOTE]

Well, that job turned out to run Q-range of 390M for 460M relations, which is a yield of less than 1.2. This is just the sort of job I'd run 33LP without a second thought; typically 70% more yield happens, which in this case would be ~2.0. At least you have enough relations to get TD140 to work!
I agree about trying pretty hard to not have to sieve above 2*lim, though I'm coming to question whether setting lim above 268M is a good idea for jobs that sieve to ~600M or so. Siever memory use and matrix difficulty seem to both jump quite a bit when changing a lim from 268M to ~400M.
I'm by no means sure this is correct, but I've been doing the following on both 14e and 15e queues:
If Q max projects to between 130M and 160M, I use 134/134M for lims.
If Q max projects to between 160M and 225M, I use 134/200 for lims (smaller lim on sieving side)
225-300 gets 200/268M (I test 134/268 also)
300-500 gets 268/268M (I may test 268/400)
500+ gets a *lot* of test-sieving and no firm plan, but 268/268 vs 268/400 vs 268/536 vs 400/400 are likely tests.

I'm downloading copies of the C228_23827_53, C215_46988659_29 and C179_374xx231_19 raw datasets, all 31-bit LPs 14e tasks. The process should finish by 15 minutes from now; then, the raw datasets can be erased from the server to reduce disk pressure.

There were some concerns earlier about the memory use of the 14e client which was surpassing the guidelines. I guess you can’t make all the people happy all the time. :smile:

One thing I did notice on the more traditional SNFS OPN jobs, where the exponent is above say 40-50 which means the size of the coefficient would only be 4 or 5 digits, one can cut the rlim is half and have no affect on the yield. This might save client memory footprint. And might also save 1-3% in timings.

For example:
[CODE]rlim: 67000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.6
alambda: 2.6[/CODE]
I suppose I should also look at pushing some of these to 30 or 31-bit jobs on 15e where larger memory usage is expected.