mersenneforum.org  

Go Back   mersenneforum.org > Factoring Projects > NFS@Home

Reply
 
Thread Tools
Old 2022-08-07, 11:33   #89
swellman
 
swellman's Avatar
 
Jun 2012

2×7×263 Posts
Default

Quote:
Originally Posted by bur View Post
That seems so low to me. A GNFS 160 takes about 160M raw relations, a GFNS 165 takes about 220 M when I do it with CADO using Curtis' optimized parameters. Is this a result of using very different parameters?
Different parameters and different tools, i.e. GGNFS/msieve vs CADO. Here we are using the historical trend for the recommended # of raw relations needed for msieve on a 30-bit job to form a matrix. But we can always kick up Q if the matrix won’t build at say target density = 110 in postprocessing.

~140M raw relations should be sufficient.
swellman is online now   Reply With Quote
Old 2022-08-07, 13:20   #90
charybdis
 
charybdis's Avatar
 
Apr 2020

35716 Posts
Default

Quote:
Originally Posted by bur View Post
That seems so low to me. A GNFS 160 takes about 160M raw relations, a GFNS 165 takes about 220 M when I do it with CADO using Curtis' optimized parameters. Is this a result of using very different parameters?
The number of relations needed is determined by the lpb bounds, not by the size of the number. Increase each lpb by 1 and you ~double the number of relations required. The mfb bounds also have an effect but it is smaller, e.g. using 3LP on one side needs maybe 20% more relations (can't remember exactly how much it is!)
charybdis is offline   Reply With Quote
Old 2022-08-07, 13:36   #91
VBCurtis
 
VBCurtis's Avatar
 
"Curtis"
Feb 2005
Riverside, CA

156116 Posts
Default

Bur-
When testing params choices on CADO, I find I need 2-3% more relations per digit for a given LP bound choice, and 70% more relations for a given input number for each increase of 1 LPB. 2% per digit adds up when we consider 10+ digit differences- a C170 on 32LP doesn't need nearly as many relations as a C185 with the same large-prime bounds (using larger lims on the C185 adds to this effect).

30LP seems really small for a C175; yield would likely double for 31LP, and 31/32 might be yet faster. Any time GGNFS yield averages below 2.5, chances are very good a larger LP choice is faster.
VBCurtis is offline   Reply With Quote
Old 2022-08-07, 16:47   #92
swellman
 
swellman's Avatar
 
Jun 2012

1110011000102 Posts
Default

Quote:
Originally Posted by VBCurtis View Post
30LP seems really small for a C175; yield would likely double for 31LP, and 31/32 might be yet faster. Any time GGNFS yield averages below 2.5, chances are very good a larger LP choice is faster.
In test sieving I first ran this as a 31-bit job and the yield was great. Would have been a perfectly fine way to sieve this job. But the upper end for 14d is 165-170, a 15e_small at lpba/r of 30 is acceptable for a G-175, and LA takes 1-2 days vs ~a week at 31-bit (system dependent of course). If it’s suboptimal, it’s only just.

Plus it was a nice break from all the monster jobs popping up lately.
swellman is online now   Reply With Quote
Old 2022-08-08, 02:26   #93
VBCurtis
 
VBCurtis's Avatar
 
"Curtis"
Feb 2005
Riverside, CA

13·421 Posts
Default

Quote:
Originally Posted by swellman View Post
...and LA takes 1-2 days vs ~a week at 31-bit (system dependent of course)..
I've never noticed this- my matrices seem to depend on input size much more than LP size, until I get to 32LP. I'd be quite surprised to learn that 30 vs 31 is more than 15% larger matrix, for a given input job.
VBCurtis is offline   Reply With Quote
Old 2022-08-08, 05:58   #94
bur
 
bur's Avatar
 
Aug 2020
79*6581e-4;3*2539e-3

601 Posts
Default

I see, so a lower lpb results in fewer relations to be found, but they are more "useful"?

The latter would be due to there being fewer unknowns in the LA problem?
bur is offline   Reply With Quote
Old 2022-08-08, 11:19   #95
charybdis
 
charybdis's Avatar
 
Apr 2020

32×5×19 Posts
Default

Quote:
Originally Posted by bur View Post
I see, so a lower lpb results in fewer relations to be found, but they are more "useful"?

The latter would be due to there being fewer unknowns in the LA problem?
2^lpb is the cutoff for the size of the largest primes/ideals that can appear in relations. Increasing lpb means that you find more relations, because you're allowing larger primes. But you also need more of them to form a matrix, because you need more relations than ideals and you've increased the possible number of ideals.
charybdis is offline   Reply With Quote
Old 2022-08-09, 06:32   #96
bur
 
bur's Avatar
 
Aug 2020
79*6581e-4;3*2539e-3

601 Posts
Default

Ah, thanks. Then it makes sense that increasing lpb by 1 doubles the number of required relations.
bur is offline   Reply With Quote
Old 2022-08-09, 14:10   #97
VBCurtis
 
VBCurtis's Avatar
 
"Curtis"
Feb 2005
Riverside, CA

13·421 Posts
Default

Quote:
Originally Posted by bur View Post
Ah, thanks. Then it makes sense that increasing lpb by 1 doubles the number of required relations.
It doesn't. The required number rises by ~75%.
Many test-sievers use "twice as many relations" as their metric, and decide the smaller LPB is faster when it's not. I've completed 32LP jobs with fewer than 300M raw relations, and 31/32 jobs with 200M raw relations (5*2^784-1 required 195M raw relations as a 31/32).

If we look at NFS@home logs, we see that 32LP jobs usually gather twice as many relations as 31LP jobs; however, most of the 32LP jobs are much more difficult than the typical 31LP job, and tougher jobs require more relations. For a given input number, 75% is the right number to use when going up an LPB on both sides, or 1/3 extra when trying a split e.g. 31/32 for LPB.
VBCurtis is offline   Reply With Quote
Old 2022-08-09, 14:50   #98
swellman
 
swellman's Avatar
 
Jun 2012

2×7×263 Posts
Default

I’ll throw into the mix that in the past BOINC seemed to have a higher percentage of bad relations than we experience today. More raw relations were needed to reach the desired number of uniques. Definitely could and should be using lower target # raw relations these days in NFS@Home.
swellman is online now   Reply With Quote
Old 2022-08-09, 15:04   #99
kruoli
 
kruoli's Avatar
 
"Oliver"
Sep 2017
Porta Westfalica, DE

22×7×41 Posts
Default

QUEUED AS 2_849p

Cullen number 849 is an SNFS 259 which is ready for sieving.
Code:
n: 4693178848105443588405037077689313140090059796932891656436699701239070186072495205194603374565187182301890731865258017239714606914206045688272187831509599345913577655908463514507873092467684232436697919148670185404630805130261264540325092481
skew: 3.22737
# skew by cownoise
size: 259
type: snfs
c6: 1
c0: 6792
Y0: -1
Y1: 2787593149816327892691964784081045188247552
rlim: 178000000
alim: 90000000
lpbr: 32
lpba: 32
mfbr: 94
mfba: 64
lss: 0
rlambda: 3.5
alambda: 2.8
To be sieved on the algebraic side (I tested all other combinations and sieving the rational side, but this one was slightly better). Test sieving blocks of 1k gave
Code:
Q	norm. yield
20M	3755
30M	3492
50M	3148
90M	2863
130M	2643
165M	2132
200M	2111
210M	2069
Therefore I suggest sieving Q 30M-195M for 440M+ relations.

I will do the LA.

Last fiddled with by swellman on 2022-08-09 at 17:00
kruoli is online now   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
2022 Queue management of 15e swellman NFS@Home 124 2022-09-26 19:01
Queue management for 14e queue VBCurtis NFS@Home 140 2022-09-20 17:33
Queue management for 16e queue VBCurtis NFS@Home 147 2022-09-08 23:54
Queue management for e_small and 15e queues VBCurtis NFS@Home 254 2022-01-02 01:59
Improving the queue management. debrouxl NFS@Home 10 2018-05-06 21:05

All times are UTC. The time now is 10:44.


Wed Sep 28 10:44:21 UTC 2022 up 41 days, 8:12, 0 users, load averages: 1.33, 1.29, 1.17

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

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.

≠ ± ∓ ÷ × · − √ ‰ ⊗ ⊕ ⊖ ⊘ ⊙ ≤ ≥ ≦ ≧ ≨ ≩ ≺ ≻ ≼ ≽ ⊏ ⊐ ⊑ ⊒ ² ³ °
∠ ∟ ° ≅ ~ ‖ ⟂ ⫛
≡ ≜ ≈ ∝ ∞ ≪ ≫ ⌊⌋ ⌈⌉ ∘ ∏ ∐ ∑ ∧ ∨ ∩ ∪ ⨀ ⊕ ⊗ 𝖕 𝖖 𝖗 ⊲ ⊳
∅ ∖ ∁ ↦ ↣ ∩ ∪ ⊆ ⊂ ⊄ ⊊ ⊇ ⊃ ⊅ ⊋ ⊖ ∈ ∉ ∋ ∌ ℕ ℤ ℚ ℝ ℂ ℵ ℶ ℷ ℸ 𝓟
¬ ∨ ∧ ⊕ → ← ⇒ ⇐ ⇔ ∀ ∃ ∄ ∴ ∵ ⊤ ⊥ ⊢ ⊨ ⫤ ⊣ … ⋯ ⋮ ⋰ ⋱
∫ ∬ ∭ ∮ ∯ ∰ ∇ ∆ δ ∂ ℱ ℒ ℓ
𝛢𝛼 𝛣𝛽 𝛤𝛾 𝛥𝛿 𝛦𝜀𝜖 𝛧𝜁 𝛨𝜂 𝛩𝜃𝜗 𝛪𝜄 𝛫𝜅 𝛬𝜆 𝛭𝜇 𝛮𝜈 𝛯𝜉 𝛰𝜊 𝛱𝜋 𝛲𝜌 𝛴𝜎𝜍 𝛵𝜏 𝛶𝜐 𝛷𝜙𝜑 𝛸𝜒 𝛹𝜓 𝛺𝜔