Let's change the NFS@home sievers!

[pinhodecarlos]

Originally Posted by frmky

Done.

I suspect you will know my following question....”your account/computing”

[RichD]

Originally Posted by VBCurtis

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.

I've done my share of 600, 700 and 800+ hour jobs to solve a 20M+ matrix. I prefer the density to be around 120 or better (for the larger ones).

[RichD]

Originally Posted by swellman

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

I have a stack of 29 & 30-bit jobs. I'll just put them into a folder when they become ready (post-ECM). Let me know when you might have a need for them. Better yet, I may put the folder in DropBox and PM you the special link. Then you can grab what you need and when you need them.

[swellman]

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

Agreed. d is never going away, but it should be used rarely. Consider DIY if warranted.

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.

Agreed, except for the cap of 180 on Q. Feels a bit arbitrary. Recognizing there is slippery slope, I’m not sure a hard limit is the best discriminator.

e vs f_small: Whatever is faster.

One word of caution from Greg - watch the lims so we don’t use too much memory. I’m probably the worst offender on this issue. Not sure what model we should use for the bigger jobs.

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.

e can probably handle a wider range of GNFS. I had suggested 180-197 earlier in this thread!

We’ve done many GNFS 19x jobs on 15e in the past. Perhaps 190 or even 192? I’m spitballing here but 184 seems an awfully low threshold before going to f_small.

[swellman]

Originally Posted by RichD

I have a stack of 29 & 30-bit jobs. I'll just put them into a folder when they become ready (post-ECM). Let me know when you might have a need for them. Better yet, I may put the folder in DropBox and PM you the special link. Then you can grab what you need and when you need them.

Sounds good. Let’s talk about it via PM sometime soon.

For now I’m just letting d slowly empty.

The part which is a complete unknown to me is the reaction of “the ever hungry grid”. Points, credits, badges etc mean nothing to me personally but I recognize that if the individual contributors aren’t happy with our setup (“behind the glass”), they will move on to another BOINC project. I have no predictions on the matter but it seems worth watching.

Should we care if d runs dry? Or throw the grid a d-bone once a week?

[VBCurtis]

I'm not sure how BOINC clients work, but if the default setup is to run a fraction of WUs on each queue, it makes sense to just feed small jobs as they come in. However, if default behavior would run more WUs on e_small when d is dry, then maybe a few days' delay for d jobs to keep the queue dry half the time or more will help us slice through e_small faster?

That said, RichD's small jobs would run through right quick, so it won't matter either way. A 30-bit job with Q-max below 80M gets sieved so quickly we shouldn't care when it gets done?

[frmky]

Originally Posted by VBCurtis

I'm not sure how BOINC clients work

The scheduler keeps jobs from all of the queues ready for assigning to users. If a user doesn't set a preference, the server will on average hand out 5 lasievef jobs and 1 job from each of the other non-empty queues. Many users, however, set a preference for jobs from only particular queues.

[frmky]

Originally Posted by pinhodecarlos

I suspect you will know my following question....”your account/computing”

Done. And badges are implemented. See CharityEngine and Gridcoin for example.

[pinhodecarlos]

Originally Posted by frmky

Done. And badges are implemented. See CharityEngine and Gridcoin for example.

Cool, thank you.

[fivemack]

Should I still be running my GNFS-20x Fibonacci numbers locally rather than trying to queue them up on _fs? I've upgraded the shed slightly (bargainhardware finally got cheap thoroughly-generic E5v3 chassis in: https://www.bargainhardware.co.uk/qu...igure-to-order) and reckon I can get through one every three months.

(the sieving jobs are 16e, 33lp with 2 rational and 3 algebraic, alim=400M, about 900MB resident)

I am inclined to put a quartic SNFS250 on _fs next

[swellman]

Originally Posted by fivemack

Should I still be running my GNFS-20x Fibonacci numbers locally rather than trying to queue them up on _fs? I've upgraded the shed slightly (bargainhardware finally got cheap thoroughly-generic E5v3 chassis in: https://www.bargainhardware.co.uk/qu...igure-to-order) and reckon I can get through one every three months.

(the sieving jobs are 16e, 33lp with 2 rational and 3 algebraic, alim=400M, about 900MB resident)

I am inclined to put a quartic SNFS250 on _fs next

Do what you think is best. Just remember to follow the new guidelines.

A quartic SNFS 250 would be a nice test case for f_small.