mersenneforum.org  

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

Reply
 
Thread Tools
Old 2022-07-24, 23:27   #78
RichD
 
RichD's Avatar
 
Sep 2008
Kansas

22×3×317 Posts
Default

Quote:
Originally Posted by swellman View Post
This is an ugly polynomial but sometimes there’s no alternative.

Cownoise gives 0.00718 for the optimal skew, for what it’s worth.

You should certainly go with 33/33.
I have little experience with these larger jobs. Whatever you or others think, feel free to change modify as needed.

Last fiddled with by RichD on 2022-07-24 at 23:29
RichD is offline   Reply With Quote
Old 2022-07-24, 23:56   #79
VBCurtis
 
VBCurtis's Avatar
 
"Curtis"
Feb 2005
Riverside, CA

3×1,877 Posts
Default

How much faster is the 16e siever for this job?

The whole point of f-small was to use the 16e siever any time it is faster than 15e. It's hard for me to believe that these jobs using Q upwards of 450M are actually faster on 15e than f-small.

Rather than continuing to place jobs on 15e to "feed" it, why don't we ask Greg to re-weight the BOINC default to assign more workunits on f-small and fewer on the smaller queues? I think he currently has 1-1-1-1-5 on the queues (5 on his big-f queue). We could change to 1-2-2-4-11 or 1-1-1-2-6 and f-small moves faster and jobs get done more efficiently (measured by total computation required).
VBCurtis is offline   Reply With Quote
Old 2022-07-25, 00:10   #80
swellman
 
swellman's Avatar
 
Jun 2012

23×13×37 Posts
Default

Quote:
Originally Posted by RichD View Post
I have little experience with these larger jobs. Whatever you or others think, feel free to change modify as needed.
The classic optimal value of skew = (1/31479823396757)^(1/6) = 0.00562766. Which is probably better than the cownoise estimate using that awful c6 value. We can go with this skew value.

Regardless of which siever it ultimately goes on.
swellman is offline   Reply With Quote
Old 2022-07-25, 00:29   #81
swellman
 
swellman's Avatar
 
Jun 2012

74108 Posts
Default

Quote:
Originally Posted by VBCurtis View Post
How much faster is the 16e siever for this job?

The whole point of f-small was to use the 16e siever any time it is faster than 15e. It's hard for me to believe that these jobs using Q upwards of 450M are actually faster on 15e than f-small.

Rather than continuing to place jobs on 15e to "feed" it, why don't we ask Greg to re-weight the BOINC default to assign more workunits on f-small and fewer on the smaller queues? I think he currently has 1-1-1-1-5 on the queues (5 on his big-f queue). We could change to 1-2-2-4-11 or 1-1-1-2-6 and f-small moves faster and jobs get done more efficiently (measured by total computation required).
Personally I agree with you in principle but the 16e_small queue is just so slow. The four jobs in its queue will take until late Oct - early Nov. And for reasons not clear to me, 15e has been very fast lately - it’s going to chew up 2_1419m1 (SNFS 284) in a little over 3 days! While this will likely be a temporary thing, I say ride the wave while it lasts.

Longer term, the downside of your suggestion is it may draw BOINC volunteers away from the big siever, something Greg may not want to see. But it’s certainly something to discuss with him, perhaps he will post here about the idea.
swellman is offline   Reply With Quote
Old 2022-07-25, 02:16   #82
charybdis
 
charybdis's Avatar
 
Apr 2020

52×37 Posts
Default

Re 1479823396757^19-1: with a skew that small you're going to have b much larger than a in your relations and lose lots of them to "b > 2^32" when it comes to msieve filtering. As long as the ggnfs siever is fine with it, I suggest inverting the roots of the polynomials to get

Code:
c6: 1
c0: -31479823396757
Y1: 31195852758590190231949248764353333010093
Y0: -1
skew: 139.27
This swaps a and b in the relations, thus getting around the above issue.
charybdis is offline   Reply With Quote
Old 2022-07-25, 03:24   #83
frmky
 
frmky's Avatar
 
Jul 2003
So Cal

72×53 Posts
Default

Quote:
Originally Posted by VBCurtis View Post
why don't we ask Greg to re-weight the BOINC default to assign more workunits on f-small and fewer on the smaller queues?
I don't mind doing this, but I doubt it'll have much effect. Most active participants manually select which queues they do. Many run only the largest queue on computers with sufficient memory, and smallest few queues on computers with less memory. This leaves the f_small queue in the awkward position of needing somewhat more memory than the lasievee queues but worth fewer credits than the lasievef queue.
frmky is online now   Reply With Quote
Old 2022-07-25, 04:49   #84
jyb
 
jyb's Avatar
 
Aug 2005
Seattle, WA

73616 Posts
Default

Quote:
Originally Posted by frmky View Post
I don't mind doing this, but I doubt it'll have much effect. Most active participants manually select which queues they do. Many run only the largest queue on computers with sufficient memory, and smallest few queues on computers with less memory. This leaves the f_small queue in the awkward position of needing somewhat more memory than the lasievee queues but worth fewer credits than the lasievef queue.
Perhaps, but it seems that something has changed in the last few weeks. It used to be the case that the e and f_small queues would get about the same amount of traffic. Similar pending work unit count at any given time, similar number of work units returned each day. But lately the work done on the e queue has more than tripled, while f_small has remained roughly unchanged. I'd be curious to know what's causing that (some particular individual/group that has explicitly chosen e for some reason?), and more importantly, whether it will continue.
jyb is online now   Reply With Quote
Old 2022-07-25, 05:22   #85
pinhodecarlos
 
pinhodecarlos's Avatar
 
"Carlos Pinho"
Oct 2011
Milton Keynes, UK

23·641 Posts
Default

It is indeed a particular client, not sure his goals, top10 overall. He did the same at numberField project. Just for the record last time he ran the project these "new" sievers were not available, probably running old settings giving 15e priority.


https://stats.free-dc.org/subproj/nfs/15e

Last fiddled with by pinhodecarlos on 2022-07-25 at 05:29
pinhodecarlos is offline   Reply With Quote
Old 2022-07-25, 06:18   #86
VBCurtis
 
VBCurtis's Avatar
 
"Curtis"
Feb 2005
Riverside, CA

15FF16 Posts
Default

Thanks, Carlos, and the rest of you for pointing out that our lack of control over clients must lead us to feed the queue that sells, so to speak.
As long as the 15e queue doesn't get long like when we started f-small, I'll hold my whining for a few more months. :)
VBCurtis is offline   Reply With Quote
Old 2022-07-25, 06:53   #87
pinhodecarlos
 
pinhodecarlos's Avatar
 
"Carlos Pinho"
Oct 2011
Milton Keynes, UK

23×641 Posts
Default

If memory doesn't betray me he ran the other project for a few months. Now looking into his stats with more detail he never ran the 16 Siever, probably back then he didn't have memory enough to run it, so he settled it with 14e and 15e only.

Last fiddled with by pinhodecarlos on 2022-07-25 at 06:54
pinhodecarlos is offline   Reply With Quote
Old 2022-07-25, 11:06   #88
RichD
 
RichD's Avatar
 
Sep 2008
Kansas

380410 Posts
Default

Quote:
Originally Posted by charybdis View Post
Re 1479823396757^19-1: with a skew that small you're going to have b much larger than a in your relations and lose lots of them to "b > 2^32" when it comes to msieve filtering. As long as the ggnfs siever is fine with it, I suggest inverting the roots of the polynomials to get

Code:
c6: 1
c0: -31479823396757
Y1: 31195852758590190231949248764353333010093
Y0: -1
skew: 139.27
This swaps a and b in the relations, thus getting around the above issue.
I adjusted the poly and ran a couple test sieves. Results follow:
Code:
      Org   New
  Q  Yield Yield
==== ===== =====
100M 12579 12612
300M  8173  8225
We are picking up a few more rels and getting better quality ones (I assume). Maybe start out going to 500M or even 450M to see how the rels are accumulating. The 300M yield seems to be an outlier, with the expected yield to be part way between 200M and 400M.

Would it be a good rule of thumb if the skew is less than, say 0.05, to perform the inversion? Another difficult poly for OPN would be for p^31-1 but not as drastic.
RichD is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Queue management for 14e queue VBCurtis NFS@Home 170 2023-01-02 15:27
2022 - queue management for 15e_small swellman NFS@Home 186 2022-12-29 17:58
Queue management for 16e queue VBCurtis NFS@Home 154 2022-12-23 21:35
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 06:38.


Tue Jan 31 06:38:26 UTC 2023 up 166 days, 4:06, 0 users, load averages: 1.23, 1.08, 0.95

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2023, 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.

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