20200220, 23:03  #67 
Jun 2012
5467_{8} Posts 
I just pointed two machines at this task. Names:
DESKTOPC5KKONV DESKTOPB1R3FI2 All seems to be working. Happy factoring! 
20200220, 23:38  #68 
"Ed Hall"
Dec 2009
Adirondack Mtns
3368_{10} Posts 
I pointed a few cores at you for a little while, as well:
math##.math## Last fiddled with by EdH on 20200220 at 23:40 
20200221, 00:39  #69 
"Ed Hall"
Dec 2009
Adirondack Mtns
110100101000_{2} Posts 
I think I broke it.
I await a verdict. . . 
20200221, 03:01  #70 
Jun 2012
5467_{8} Posts 
My machines lost contact...had to retask one of my machines as it didnâ€™t meet recommended memory specs. DESKTOPB1R3FI2 still active but seemingly just spinning in circles.

20200221, 03:24  #71 
"Ed Hall"
Dec 2009
Adirondack Mtns
2^{3}·421 Posts 
I missed the memory requirement part. Are my machines too weak to play? I hope that wasn't what broke it. . .
I have been having troubles with the latest CADONFS revision stopping handing out WUs. I did not have that trouble with my previous revision. 
20200221, 05:08  #72 
"Curtis"
Feb 2005
Riverside, CA
3·31·47 Posts 
Memory requirement is likely 24GB for the system, as the process takes just under 20GB according to top.
Since only 80 or so workunits had been completed when we ran the job out of failed units, I decided to restart the job at Q=5.08M. I can just cat the relations from the first folder together with these when I send them to Greg. When perusing the log, I noticed that every workunit included a mention of buckets full, so I added bkmult=1.12 in an effort to reduce the number of retried/recalculated Q values. This should result in a singledigit percentage speed gain, though memory use may be marginally higher (I'll edit this post once I find out). CADO is generating free relations now, and will be ready to hand out workunits on port 44455 within ten minutes or so. This time, the port is specified, so the inevitable serverkicking won't potentially change the port. Edit: WUs available. Memory use still 19.5GB according to top. Last fiddled with by VBCurtis on 20200221 at 05:26 
20200221, 15:26  #73 
"Ed Hall"
Dec 2009
Adirondack Mtns
6450_{8} Posts 
Well, sorry if I caused a lot of reissue of WUs.
I had an "interesting" time, here! I typically shut down about half my farm at night. When I shut them down last night many were the ones I had tasked with this project. They went off line, but this morning, I found them back on and tying up the LAN. They were trying to get work again. I had to physically unplug, hold power buttons and reboot to get them operating normally again. I'll try to pay more attention next time. . . 
20200221, 18:04  #74 
"Carlos Pinho"
Oct 2011
Milton Keynes, UK
2·5·11·43 Posts 
When the time comes you can direct your efforts to mersenneforum team at NFS@Home by running BOINC client. https://escatter11.fullerton.edu/nfs...hp?teamid=2082

20200224, 21:05  #75 
Jul 2003
So Cal
3^{2}×227 Posts 
OK, I realized that I'm a bit of an idiot. This is a GNFS sextic at the edge of where we should be using a sextic, so the algebraic side is going to be by far the largest. So we need to choose q's on that side, and put the 3LPs on that side. That's not what I did.
So with the proper parameters, this one isn't that hard at all. Even with my usual lowermemory parameters below, q of up to 3.5 billion are enough. That's officially routine for NFS@Home. Code:
alim: 250000000 rlim: 250000000 lpbr: 33 lpba: 33 mfbr: 67 mfba: 96 rlambda: 2.8 alambda: 3.7 
20200225, 05:21  #76 
"Curtis"
Feb 2005
Riverside, CA
3·31·47 Posts 
OK, I've restarted CADO at Q=5.5M with the new lim values. Due to ignorance, I left CADO to sieve on its default side, which happened to be the algebraic side. That might explain why I was 4x faster than the r side ggnfs test sieve!
I have 3M or so relations from Q=5M to nearly 5.5M. I'm starting at 5.5M in case those relations are useful; if they're not (I don't think they are), I can run 45.5M if time permits. The usual address (same as C207 from last summer), port 44455. EDIT: I was paying even less attention than I thought I also had set mfba to 96. I originally flipped side 0 and side 1 on CADO, not for the first time, so I accidentally ran the params Greg has recently specified, except for lim's at 536M rather than 250M. That lim is the only change is why I think there's a tiny chance the first 3M rels I gathered may be useful. For those watching at home: Side 0 is rational, side 1 is algebraic. See the params.c90 file for more details. Default sieve side is side 1 (if left unspecified). Last fiddled with by VBCurtis on 20200225 at 05:30 
20200225, 05:59  #77 
Jul 2003
So Cal
3^{2}×227 Posts 
They absolutely are useful. As long as the polynomial is correct, the relations will be valid. Sieving on a different side with different limits will still produce valid relations.
In fact, it's quite useful to sieve the lower q that you are doing with higher limits as long as the higher memory use isn't a problem. So you might to back to sieving on the algebraic side with 536M limits and 3 large primes on the algebraic side. 
Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Poly select and planning for 2,2330M  VBCurtis  Cunningham Tables  69  20200508 06:39 
Poly select and planning for 2,2210M  swellman  Cunningham Tables  51  20200322 22:09 
Poly select and testsieving for RSA232  VBCurtis  Operation Kibibit  25  20200107 01:57 
YAFU Poly Select Deadline  amphoria  YAFU  22  20160917 09:47 
Starting NFS skipping poly select  jux  YAFU  5  20160102 01:01 