2022 Queue management of 15e

[RichD]

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.

[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).

[swellman]

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.

[swellman]

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.

[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

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.

[frmky]

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.

[jyb]

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.

[pinhodecarlos]

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

[VBCurtis]

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. :)

[pinhodecarlos]

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.

[RichD]

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

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:

      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.