Let's change the NFS@home sievers!

[frmky]

I moved the GNFS-191 over as a test of the new f_small queue. In the process I lowered the limits and moved sieving to the algebraic side. I didn't benchmark these changes; just felt right.

[chris2be8]

Originally Posted by VBCurtis

I picked out a current SNFS job (from Chris2be8: https://mersenneforum.org/showpost.p...postcount=2464) to test memory use.

That job is pushing the limits of a 31 bit job on 14e. I was considering making it a 32 bit job, but then downloading the relations could easily take me nearly as long as solving the matrix.

I'll be very happy to switch to 15e_small as soon as it's open.

Chris

[pinhodecarlos]

Originally Posted by frmky

I moved the GNFS-191 over as a test of the new f_small queue. In the process I lowered the limits and moved sieving to the algebraic side. I didn't benchmark these changes; just felt right.

Will you link it to a new application or to the old ones. I still can’t see it on my account (NFS@Home preferences)these extra two applications.

[swellman]

Originally Posted by pinhodecarlos

Will you link it to a new application or to the old ones. I still can’t see it on my account (NFS@Home preferences)these extra two applications.

I believe you just need to refresh/reload https://escatter11.fullerton.edu/nfs/

The new queues were visible this morning.

ETA: never mind. Ignore the above.


As to enqueuing new work, my notion is that if there’s doubt then there is no doubt (Bobby D forgive me). IOW if you’re not really sure if your job is appropriate for a given siever then likely it’s not and should be sieved by the next higher siever.

All to be verified with test sieving of course.

[VBCurtis]

nfs@home home page shows e_small and f_small.

So, we need to work out guidelines for the queues.

d vs e_small: If test-sieving indicates 15e could be even possibly faster, send it to e_small. Some 30-bit jobs will be best on e-small. It should be somewhat normal for d to be dry, and we should resist the temptation to feed d just because it has no queue. If you'd use 31LP on 14e, you should be considering/comparing at 15e test sieve and e_small.

e_small vs e: My vote for e_small is Lim cap at 134M, Q cap at 180M (perhaps lower). That doesn't leave too much for e, but the jobs that go on e will be twice as long (or longer) than most of e_small; I don't know how much we care, anyway.

e vs f_small: Whatever is faster.

Once we reach a consensus here, I'll make a sticky with guidelines as condensed as possible.
GNFS example:
d: under 168 digits
e_small: 168 to 179 digits
e: 180 to 184 digits
f_small: 185+ digits
Where is the exact 14e vs 15e cutoff for GNFS? I'm guessing at 168.

[VBCurtis]

Originally Posted by frmky

I moved the GNFS-191 over as a test of the new f_small queue. In the process I lowered the limits and moved sieving to the algebraic side. I didn't benchmark these changes; just felt right.

Sean-
On the C191, looks like Q-range didn't get shrunk; 30-300M is likely to get you way way way oversieved from 16e. Consider taking the time to make a handful of filtering runs with varying numbers of relations, so we can learn the effects of oversieving at this size. You might get a matrix under 20M from a 16e job!

[RichD]

Originally Posted by VBCurtis

Sean-
... Consider taking the time to make a handful of filtering runs with varying numbers of relations, so we can learn the effects of oversieving at this size. You might get a matrix under 20M from a 16e job!

I have a bunch of heuristic from 14d. Not sure if they will correlate with15e or 16f.

For 32-bit jobs (14d) a good starting point is around 340M unique. One can get a matrix using TD=12x. Around 360M unique a matrix can be built with TD=13x. Above 370M it will be over-sieved such that the TD build will start decreasing. I did have one job at 340M build using TD=140 but that is the exception.

[VBCurtis]

Thing about data like that is that it depends so much on job difficulty. I've run 14e/32 on GNFS-164 and GNFS-174, and the number of relations needed for the two jobs were quite different- like 25% higher for 174. 340M unique is quite a lot of relations, seems like overkill for 14e jobs!

The GNFS-191 that Sean will run is specifically a size representative of the new f_small queue, and bigger jobs respond better to oversieving in the sense that matrix sizes can be cut nearly in half when compared to a number of relations that builds a "reasonable" (say, TD 100) matrix.

[swellman]

Originally Posted by VBCurtis

Sean-
On the C191, looks like Q-range didn't get shrunk; 30-300M is likely to get you way way way oversieved from 16e. Consider taking the time to make a handful of filtering runs with varying numbers of relations, so we can learn the effects of oversieving at this size. You might get a matrix under 20M from a 16e job!

I will watch it and periodically run filtering (and post the log).

[frmky]

Originally Posted by pinhodecarlos

Will you link it to a new application or to the old ones. I still can’t see it on my account (NFS@Home preferences)these extra two applications.

Done.

[swellman]

Please note I’ve queued 8p7_320 on lasievee_small. It’s a SNFS 231 quartic that isn’t suitable for lasieved but is a perfect fit for lasievee_small. It’s a 31-bit/134M/3 LP job (on the rational side).

Unless someone objects, I’ll start the sieving process on that job later this evening.

I pushed all remaining lasieved jobs into sieving - all sieving WUs should be pushed out by next weekend.

To repeat what was written earlier - please resist the urge to request jobs be added to the lasieved queue if possible. I don’t think lasieved is completely going away but jobs there should become scarce(r).