mersenneforum.org 2022 Queue management of 15e
 Register FAQ Search Today's Posts Mark Forums Read

2022-07-24, 23:27   #78
RichD

Sep 2008
Kansas

22×3×317 Posts

Quote:
 Originally Posted by swellman 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

 2022-07-24, 23:56 #79 VBCurtis     "Curtis" Feb 2005 Riverside, CA 3×1,877 Posts 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).
2022-07-25, 00:10   #80
swellman

Jun 2012

23×13×37 Posts

Quote:
 Originally Posted by RichD 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.

2022-07-25, 00:29   #81
swellman

Jun 2012

74108 Posts

Quote:
 Originally Posted by VBCurtis 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.

 2022-07-25, 02:16 #82 charybdis     Apr 2020 52×37 Posts 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.
2022-07-25, 03:24   #83
frmky

Jul 2003
So Cal

72×53 Posts

Quote:
 Originally Posted by VBCurtis 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.

2022-07-25, 04:49   #84
jyb

Aug 2005
Seattle, WA

73616 Posts

Quote:
 Originally Posted by frmky 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.

 2022-07-25, 05:22 #85 pinhodecarlos     "Carlos Pinho" Oct 2011 Milton Keynes, UK 23·641 Posts 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
 2022-07-25, 06:18 #86 VBCurtis     "Curtis" Feb 2005 Riverside, CA 15FF16 Posts 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. :)
 2022-07-25, 06:53 #87 pinhodecarlos     "Carlos Pinho" Oct 2011 Milton Keynes, UK 23×641 Posts 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
2022-07-25, 11:06   #88
RichD

Sep 2008
Kansas

380410 Posts

Quote:
 Originally Posted by charybdis 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.

 Similar Threads Thread Thread Starter Forum Replies Last Post VBCurtis NFS@Home 170 2023-01-02 15:27 swellman NFS@Home 186 2022-12-29 17:58 VBCurtis NFS@Home 154 2022-12-23 21:35 VBCurtis NFS@Home 254 2022-01-02 01:59 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