View Single Post
Old 2020-08-31, 02:39   #1
VBCurtis's Avatar
Feb 2005
Riverside, CA

47·101 Posts
Default Let's change the NFS@home sievers!

After nearly 10 years in service, the 14e queue has outlived its usefulness. Most of the workunits (not jobs) in 14e are for numbers that would be faster on 15e, but the 15e queue is lengthy and the 14e queue often runs dry, so they're sent to 14e somewhat wastefully.

So, why don't we retire 14e, and change lasieved to the 15e siever? In order to maintain three BOINC projects within NFS@home, I have a couple of ideas:

1. lasieved w/15e jobs should have lim's restricted to maintain a low-memory option for users on older machines. Limits of 134/200M or 134/134M would keep memory use about where it is now (note some 14e jobs use lim's of 268M!) Note this limit would not be hard-coded, so we could let it rise over the years as jobs and memory capacities get bigger.

2.If we change d to 15e, the lasieve-e BOINC project should change to 16e (or, failing that, 15e -J 15). Many of the current "e" jobs would be more efficient on 16e, and the queue is long in part because of these huge jobs. Further, there are quite a few GNFS-190+ or SNFS-275+ jobs of interest among the projects we collectively care about, so this queue would stay well-fed and yet faster than the current arrangement (since each job of that size is faster on 16e than 15e).

For me, the second change is not required by the first- we could have 15e-small and 15e-big for the two queues and still come out more efficient overall.

Note that going to larger sievers also tends to make smaller matrices for each job, or equivalently require somewhat fewer relations to yield a matrix.

1. Lots of small-15e jobs are currently homeless, either waiting months in the 15e queue or wasting resources on 14e. These jobs are very common in our work now, and the jobs continue to grow over time. It's worth it to change now, and will become more valuable in the future.

2. We have the hardware to handle matrices of 50M size, and using 16e would allow us to handle up to GNFS-205 or SNFS-300 (? Not sure, I don't do much SNFS) without troubling Greg on the big queue.

1. Some small jobs, e.g. 14e with 30LP or smaller, will be less efficient on 15e than 14e. This computational waste is much less than the savings available from jobs currently run as 14e/32, e.g. GNFS-175ish. The really small ones (e.g.. GNFS 155 or less) can be done on a home desktop anyway.

2. Memory use might rise on the "e" queue. We should be careful to keep 16e lim's small at the outset to make sure memory use doesn't drastically change if we do this.

3. If "d" queue has a strict lim cap, there will still be a size of job that's homeless, with 16e slow but 15e/134M too restrictive. We can handle this as it happens, likely by sending to whichever queue is shorter.

4. Greg might not have time nor interest in the effort required to make this change happen.

VBCurtis is offline   Reply With Quote