mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Aliquot Sequences (https://www.mersenneforum.org/forumdisplay.php?f=90)
-   -   Reserved for MF - Sequence 3408 (https://www.mersenneforum.org/showthread.php?t=18421)

RichD 2013-07-11 06:41

Reserved for MF - Sequence 3408
 
I have received a note from Christophe stating sequence 3408 is available for advancement. It currently stands at index 1287 with a c152 remaining. (FDB has been updated with his log file.) Accordingly, it is ready for GNFS. Now we just need a poly... hint, hint.

He posed two questions that I can not answer and will post to the community.

[QUOTE]Please could you confirm me that you reserve 3408 if you are happy with it?
Also, should I consider that you release 4788?[/QUOTE]Could someone with a higher pay scale provide these answers?
I will let him know of our decision in the next email.

P.S. 2 * 3^2 * 23 * c152

[URL="http://factordb.com/sequences.php?se=1&eff=2&aq=3408&action=last20&fr=0&to=100"][U]Link[/U][/URL] to sequence 3408 in the database.

VBCurtis 2013-07-13 10:07

I can handle poly select for it this week, but what makes you sure it is ready for GNFS now?

RichD 2013-07-13 21:44

[QUOTE=VBCurtis;346177]I can handle poly select for it this week, but what makes you sure it is ready for GNFS now?[/QUOTE]

Thanks.

From Christophe:
"The c152 cofactor has been tried 5600 curves at B1=11e6 and 8100 curves at B1=43e6. I think its time to gnfs it."

VBCurtis 2013-07-14 04:31

Fair enough- I can have a poly in a few days for you. I'd appreciate someone indulging my laziness and posting the composite here, since I don't have a ton of experience retrieving individual numbers from the db.

There is a thread in the msieve forum where a couple of us who are trying to gain familiarity with the msieve tools are running GPU poly select on candidates 150+ digits posted by anyone who wants the help. If this effort continues, consider posting the big composites in there- good polys are often produced in a day or two by one of us.

-Curtis

RichD 2013-07-14 04:43

[QUOTE=VBCurtis;346278]I'd appreciate someone indulging my laziness and posting the composite here, ...[/QUOTE]

OK, and will remember your offer by posting in the other thread.

A3408:i1287
[CODE]25797575131790381764317406030419543530247871027977137938177849677244690157065100738893911971862010361529679087277839665771863704705529497481575938310123[/CODE]

RichD 2013-07-14 06:06

Oh silly me. I could have provided a link to the [URL="http://factordb.com/sequences.php?se=1&aq=3408&action=last"]last term[/URL].

RichD 2013-07-15 02:37

It looks like I may have stepped out of bounds. Is there any interest in advancing low numbered sequences as a team effort? Could a Mod present a poll to see if "the forum" should release 4788 and/or take on 3408? If nothing else, I can advance 3408 a couple indexes myself.

VBCurtis 2013-07-15 05:40

Rich-
I'm interested in learning how to manually set GGNFS commands to assist with a team sieve- so I'll offer a couple cores of assistance for 3408 to advance a bit, assuming we decide on a method for transferring you the data.

Here are the only two decent polys I found for the C152:
[CODE]# norm 9.745627e-015 alpha -7.744336 e 3.793e-012 rroots 3
skew: 1341467.56
c0: -2517106373804145181364286197055054075
c1: -181618619647482158982503505948
c2: -6280170503010468554850924
c3: -16534603320158905976
c4: 15888436541215
c5: 3003900
Y0: -97001535586366271156398420418
Y1: 15535061495212391 [/CODE]

almost tied in score:
[CODE] # norm 9.610087e-015 alpha -6.026309 e 3.779e-012 rroots 5
skew: 245227.61
c0: -6897520423128801498842225861018080
c1: 13052139425774434204133751403
c2: 1788987296416905005831341
c3: 2268360959361746978
c4: -34520814515709
c5: 6300540
Y0: -83645054002236074626072321611
Y1: 7612890022579361 [/CODE]

I had only one other poly above 3.55, in 800MB of np1 hits and 50 hr of -nps.

RichD 2013-07-22 21:32

[QUOTE=VBCurtis;346360]Rich-
I'm interested in learning how to manually set GGNFS commands to assist with a team sieve- so I'll offer a couple cores of assistance for 3408 to advance a bit, assuming we decide on a method for transferring you the data.[/QUOTE]

Thanks VBCurtis,

Sorry it sat so long but I just got back from a short trip. I'll put together the other parameters and instructions and post them later today.

debrouxl 2013-08-02 18:59

The C122 at index 1292 has received t35 @ B1=3e6 (600 curves).

RichD 2013-08-02 23:07

3408:i1292
 
[QUOTE=debrouxl;348051]The C122 at index 1292 has received t35 @ B1=3e6 (600 curves).[/QUOTE]

I'm thinking the C122 needs about 1t40 or 900 @ 11e6 plus all curves at 3e6.

Oh, but wouldn't 900 @ 11e6 be enough to cover the t40 @ 3e6??

Anyway, I should be close to 900 @ 11e6 later tonight and will start GNFS for an overnight run if a factor doesn't pop up before then.

debrouxl 2013-08-03 06:33

Exactly, the C122 needs about t40, but I just wanted to mention that I had done a bit less than a quarter of that :smile:

RichD 2013-08-03 14:49

[QUOTE=debrouxl;348086]Exactly, the C122 needs about t40, but I just wanted to mention that I had done a bit less than a quarter of that :smile:[/QUOTE]

Sure, that was helpful. It got me thinking when I started my run at 11e6, I included your contributions.

Now, at index 1293, stands a c144.

c10ck3r 2013-08-03 16:13

3408:1299 C121

RichD 2013-08-03 16:44

[QUOTE=c10ck3r;348116]3408:1299 C121[/QUOTE]

Correct. I'm almost to t40 and will start GNFS shortly.

RichD 2013-08-04 06:04

Seq 3408
 
Status update.

Now at 3408:i1304 C130 with no ECM.

I will be away for a few days if anyone would like to advance this.

Currently at 2 * 3^3 * 13 * p12 * p12 * c130.

rajula 2013-08-04 06:18

I'll continue with trivial ecm for a couple of hours. The C130 surrendered to ECM and now a C126.

BTW, should this discussion be moved to some other thread?

rajula 2013-08-04 08:22

I'll stop my tiny ECM run at 3408:i1309 with the c120 having had 400@11e6.
We currently have 2 · 3^4 · 5 · 383 · p7 · p26 · c120

thomasn 2013-08-05 04:37

i1309:
PRP46 = 1368593979590886700989697321280426303690904121
PRP75 =111961333888662658883684615537026245063012808973517402564491241834875042681

I have done no ecm on the C150 at i1310.

RichD 2013-08-06 20:46

[QUOTE=thomasn;348275]I have done no ecm on the C150 at i1310.[/QUOTE]

I've started with:
-pm1 3e9
-pp1 1e9
(I don't know why I even do -pp1. I can't remember the last time I found a factor with it.)

600 @ 11e6
180 @ 43e6

Once we get a solid t50 I can put a request in for a poly over at the Msieve thread.

Andi_HB 2013-08-06 21:16

800 @ 1e6 done

RichD 2013-08-07 02:39

Total updated counts are passing through.

1230 @ 11e6
440 @ 43e6

Andi_HB 2013-08-07 08:51

1750 @ 3e6 are done - no factor

RichD 2013-08-07 14:43

Passing through.

2500 @ 11e6 - done
860 @ 43e6

RichD 2013-08-08 01:32

I'm passing through

1800 @ 43e6

EdH 2013-08-08 03:25

Add in 1490 more @11e6

EdH 2013-08-08 23:46

[code]
math55@math55:~/Math/ecmWork$ python ecm.py -threads 2 -c 2000 43000000 <ecmTest
-> ___________________________________________________________________
-> | Running ecm.py, a Python driver for distributing GMP-ECM work |
-> | on a single machine. It is Copyright, 2012, David Cleaver and |
-> | is a conversion of factmsieve.py that is Copyright, 2010, Brian |
-> | Gladman. Version 0.10 (Python 2.6 or later) 30th Sep 2012. |
-> |_________________________________________________________________|

-> Number(s) to factor:
-> 158562617349742945209675705641056807898933509464973267150675418846057564672877363454894115116065225867039062557863618865761425909629304410855170704171 (150 digits)
->=============================================================================
-> Working on number: 158562617349742945...304410855170704171 (150 digits)
-> Currently working on: job0685.txt
-> Starting 2 instances of GMP-ECM...
-> ./ecm -c 1000 43000000 < job0685.txt > job0685_t00.txt
-> ./ecm -c 1000 43000000 < job0685.txt > job0685_t01.txt

GMP-ECM 6.4.4 [configured with GMP 5.1.2, --enable-asm-redc] [ECM]
Using B1=43000000, B2=240490660426, polynomial Dickson(12), 2 threads
Done 197/2000; avg s/curve: stg1 148.2s, stg2 43.34s; runtime: 18935s

Run 197 out of 2000:
Using B1=43000000, B2=240490660426, polynomial Dickson(12), sigma=354488151
Step 1 took 147205ms
Step 2 took 43231ms
********** Factor found in step 2: 36471335428481436387054163147551565208686210066640946173017
Found probable prime factor of 59 digits: 36471335428481436387054163147551565208686210066640946173017
Probable prime cofactor 4347595597662628436638238052393245639270024035804982296756254715893080250256191319569347363 has 91 digits

math55@math55:~/Math/ecmWork$
[/code]

RichD 2013-08-08 23:51

Wow! A p59 at t50!!

As I was closing in on 4000 @ 43e6.

RichD 2013-08-09 18:29

c155 @ i1311
 
1000 @ 3e6 - nothing
passing through 500 @ 11e6

Edit: and -pm1 2e9

RichD 2013-08-10 06:00

2850 @ 11e6 - nothing
Passing through 50 @ 43e6

BTW, I intentionally don't complete a level incase others are working it and haven't reported their work. Backfilling can always be done at the end before starting GNFS.

RichD 2013-08-11 20:15

1300 @ 43e6 - nothing.

RichD 2013-08-13 02:06

Getting back into this one after needing all cores for an NFS job.

Passing through 800 @ 43e6
(Total of 2100 so far by me.)

VBCurtis 2013-08-13 04:18

Does the plan call for a full t50 for this one?
Rephrased: What ratio of ECM-test to digit-length is standard around here?

I don't have threads to spare for a few days, so firejuggler might have to poly-select this one too.

RichD 2013-08-13 05:16

There tends to be two flavors floating around. The one I usually follow is the 1/3 GNFS rule. So this number is 155/3 or about 51.67 or a full t50 plus nearly 2/5 of t55, or another 6000 @ 11e7. We are still days, if not weeks, away from poly selection time.

Passing through
1150 @ 43e6

prgamma10 2013-08-13 06:26

GNFS 155 job takes 5-6 weeks on my computer, and a full t50 takes 9 days on the same machine.

prgamma10 2013-08-14 08:54

[QUOTE=prgamma10;349375]GNFS 155 job takes 5-6 weeks on my computer, and a full t50 takes 9 days on the same machine.[/QUOTE]
Sorry, it takes about 4 (instead of 5-6) weeks, so I use (GNFS digits [B]- 6[/B])/3 rule.

RichD 2013-08-14 14:03

This will most likely be a team sieve.

Passing through 5240 @ 43e6
(total of 6540 @ 43e6)
Switching a core to 11e7.

RichD 2013-08-14 14:11

(Didn't see the second post until now.)

[QUOTE=prgamma10;349505]... so I use (GNFS digits [B]- 6[/B])/3 rule.[/QUOTE]

Is that like a sliding scale as you get up into larger numbers?

prgamma10 2013-08-14 15:52

(English is not my first language)
[QUOTE=RichD;349529]This will most likely be a team sieve.
[/QUOTE]
It's just my opinion though.
[QUOTE=RichD;349530](Didn't see the second post until now.)
Is that like a sliding scale as you get up into larger numbers?[/QUOTE]
I use the timing from a GNFS 155 job I ran with the 64-bit siever, then divide it with four to get ECM time.
Because the 64-bit siever brings 2x speedup over its 32-bit counterpart, and each 6 digits added also mean 2x longer job, I think 6 is to be subtracted from the GNFS digits first.

RichD 2013-08-14 22:08

I understand what you doing. It looks like we are about poly ready. I'll make a request over in the Msieve thread.

Another 6285 @ 43e6 - nothing

Switching all to 11e7.

prgamma10 2013-08-15 16:31

Running P-1 @ 1e10...

prgamma10 2013-08-15 19:37

[QUOTE=prgamma10;349666]Running P-1 @ 1e10...[/QUOTE]
No factor.

RichD 2013-08-16 17:58

2500 @ 11e7 - nothing.

We got a good poly thanks to [B]firejuggler[/B] so it's time to sieve this number.

RichD 2013-08-27 16:54

c153 @ i1312
 
2 * 3^2 * 12637 * c153

-pm1 3e9 - nothing

Batalov 2013-08-27 17:44

It's cracked.

RichD 2013-08-28 03:25

c148 @ i1322
 
2 * 3^2 * 59 * 1823 * 113089 * c148

-pm1 3e9 - nothing.

EdH 2013-08-28 11:37

2360@3e6
2000@11e6
>750@43e6

EdH 2013-08-28 15:41

>2000@43e6

RichD 2013-08-28 20:03

>600 @ 43e6

EdH 2013-08-29 02:22

>2600@43e6 (total)
>1000@11e7

RichD 2013-08-29 04:32

>1350 @ 43e6 (total)

Looks like we are closing in on the equivalent of t50 which is all that is needed before GNFS. I'll let mine run until morning then switch to something else.

Someone with big iron (Core-i7 or hex-core) can knock this out in under a week. Or someone with distributed sieving or requesting help in a few ranges can also do it. It may not be worth the overhead to try a team sieve, but first a poly is needed. I don't think all the GPU-poly searchers are currently busy. It might be time to make a request in this [URL="http://mersenneforum.org/showthread.php?t=18368"]thread[/URL], or I can. I'm only in town for six more days so I may not be much help on this one.

RichD 2013-08-29 12:37

2000 @ 43e6 - nothing.

RichD 2013-09-14 07:26

c162 @ i1361
 
2 * 3^4 * c162

Just starting 11e6.

RichD 2013-09-14 18:23

c162
 
-pm1 5e9 - nothing
>1000 @ 11e6 - nothing.

RichD 2013-09-15 01:47

> 2300 @ 11e6 - nothing.

After the 11e6 level we will need an additional
7550 @ 43e6
14215 @ 11e7
before NFS ready.

I wonder if [B]yoyo[/B] or others would be willing to help with these curves.

EdH 2013-09-15 03:18

@RichD: Welcome back - hope you had a great time. I've been plugging along, but ran into this stubborn composite.:sad:

Just to let you know:
>1800@1e6
>4700@3e6
>7700@11e6
>4000@43e6
>1500@11e7

I've been playing with my scripts and restarting a lot, so I don't have accurate counts on any of these B1 runs, but I have at least the numbers shown...

VBCurtis 2013-09-15 04:43

Looks like Ed has finished a t50 already, so the rest of your curves should be at 11e7.
Good luck!

RichD 2013-09-15 04:48

Great progress on the c162.

Add in my 2700 @ 11e6.

Switching to 11e7.

Looks like a poly selection may be in our future. :smile:

RichD 2013-09-16 02:13

c162
 
> 500 @ 11e7

I think a bit too early to request a poly.

EdH 2013-09-16 03:35

Now over 2250@11e7 and an unknown quantity at 43e7. My script is not echoing properly and many of my machines are giving multiple errors:
[code]
-> *** Error: unexpected return value: -9
[/code]which is throwing off the counter in the script, that won't display anyway..

I know it is >400@43e7, but I don't know how many more...

RichD 2013-09-16 04:11

I have several dozen @ 26e7. Using the typical multiplier of 3x, I've added 150+ @ 11e7 because of that.

Give it another day and I'll add more cores @ 11e7 we will be approaching NFS soon.

EdH 2013-09-16 18:02

The best count I came up with for 43e7 is 523 completed out of the 2000 assigned, due to errors cancelling assignments. Only a couple of my machines appeared to work through their assignments without errors.:sad:

I have stepped back to 26e7 for the time being to see how they run...

henryzz 2013-09-16 19:06

43e7 will require quite a substantial amount of memory. Do you have enough? Is that your problem on some machines?

EdH 2013-09-16 20:57

[QUOTE=henryzz;353172]43e7 will require quite a substantial amount of memory. Do you have enough? Is that your problem on some machines?[/QUOTE]
Quite probably the issue! My array is a hodgepodge of systems, some very limited. Of the weakest, they don't do any, while others will do some before the failure and then perform some more before the next failure. I'm running all of the ecm via ecm.py and it restarts at the failure point, so if 4 were successful of 20, it starts there. Some of the failing machines eventually completed all 20; some never made it through 1.

Thanks!

EdH 2013-09-17 16:18

Current total: 1230@26e7...

RichD 2013-09-17 18:17

c162
 
I need to reboot because of system software updates.

2172 @ 11e7
217 @ 26e7
(or the equivalent of 2820 @ 11e7 - if my math is right.)

EdH 2013-09-18 03:00

c162
 
current total: 1850@26e7

VBCurtis 2013-09-18 06:59

I'm running a poly select for a C136 overnight, so I'll begin poly selection for this C162 late Wed evening. You should still post it tomorrow in the request thread, since this is enough number to profit from multiple searchers.

Ya'll have some pretty serious ECM resources to get this 11e7 level done in just a couple days.
-Curtis

EdH 2013-09-18 18:35

current total: 1931@26e7

EdH 2013-09-19 00:13

c162
 
I still have a couple machines finishing their 26e7 assignments, but have switched everything else over to 11e7 since I still have many errors showing at 26e7. The new count of curves@11e7 will not include the 2250 I already posted in #60 above. Currently, I'm closing in on 700@11e7 new curves. I'll post an actual count later on. I suppose I'll stick with 11e7 until we have a poly (or, more preferably, a factor shows up via all this ecm).

RichD 2013-09-19 00:44

c162
 
New counts are:

>780 @ 11e7
>200 @ 26e7

I used the -v switch to calculate the ratio between curves in ECM. t55 requires
11e7 @ 17884 x1
26e7 @ 7650 x2.34
43e7 @ 4958 x3.61

If I followed the thread and added the numbers properly we have at:
11e7 2250 + 2172 + 700 + 780 = 5902 x1 = 5902
26e7 1931 + 217 + 200 = 2348 x2.34 = 5494
43e7 453 = 453 x3.61 = 1635
Grand total (so far) of 13031
of which 4/5 of 17884 (or 14.3K) is needed.

I'll let mine run through the night and request a poly.
I may even run a few dozen @ 85e7 to flush out a near miss.

EdH 2013-09-19 04:41

I'm letting my machines finish what should be a total of 2000@11e7 (which includes the aforementioned 700), overnight. I'm hoping all machines will show clear (and paused) in the morning. Then I'll evaluate the next course...

henryzz 2013-09-19 08:08

Are you using any of the memory saving options with 26e7?
Bear in mind as well that 20e7 might work and provide a better chance of large factors.

EdH 2013-09-19 13:49

c162
 
I have >1950@11e7 of the latest set. I seem to have some machines lagging a bit and I can't account for all of the curves. That's one reason for the script change. So that's 1950 on top of the 2250 from from post 60.

After I get the new scripts running, I'll try whatever@20e7 for a while to see how they run...

[QUOTE=henryzz;353419]Are you using any of the memory saving options with 26e7?
Bear in mind as well that 20e7 might work and provide a better chance of large factors.[/QUOTE]
Thanks! I'll alter my script to 20e7 and try running those. I'm making a major script change today, anyway. It will fit right in. As to the memory saving options, no. I'm using a single command line that provides the same command to each machine. That command line invokes ecm.py. Can I alter ecm.py to incorporate the options? I haven't looked into them.

henryzz 2013-09-19 15:19

ecm.py is designed to support the options being passed to it not having defaults.
If you need the same command to each machine to start ecm.py then I would suggest starting ecm.py using a script with the options added in the script. I would guess that -maxmem is probably the best for you. The other methods give more control but require optimizing for different B1s.

Hacking ecm.py would be possible although not trivial.

RichD 2013-09-19 17:05

[QUOTE=RichD;353377]New counts are:

>780 @ 11e7
>200 @ 26e7[/QUOTE]

My final (additional) counts.

1120 @ 11e7
305 @ 26e7
20 @ 85e7

EdH 2013-09-19 21:03

I have my new scripts in place, so I'll be testing them with 20e7 to see how they run. I'll probably just stay with 20e7 until we decide to sieve...

RichD 2013-09-19 23:23

With your counts I believe we have surpassed the minimum needed. Of course, an ECM find now would save tons of sieving. I've switched to Seq 3366.

There are three people working on the poly in different search spaces. I'm also working on c173 for 4788:i5154 but the c162 will be the first one out the door.

EdH 2013-09-20 03:23

[QUOTE=RichD;353499]With your counts I believe we have surpassed the minimum needed. Of course, an ECM find now would save tons of sieving. I've switched to Seq 3366.

There are three people working on the poly in different search spaces. I'm also working on c173 for 4788:i5154 but the c162 will be the first one out the door.[/QUOTE]
I've got >600@2e8 now and counting. I am still getting some errors, but not too many and the scripts allow for restarts whenever I get one. Counting has to be done manually, but I have a count built into the script output for each machine that isn't too bad to use. I just have to check each machine. I'll keep these going @2e8 for now.

I see that the poly for 4788 (c173) is finished, but that's going to be a long project. I'm wondering about this c162. I may not be able to start sieving until Sunday, due to a couple of other things going on...

RichD 2013-09-20 04:36

[QUOTE=EdH;353521]I see that the poly for 4788 (c173) is finished, but that's going to be a long project. I'm wondering about this c162. I may not be able to start sieving until Sunday, due to a couple of other things going on...[/QUOTE]

I'm trying to get the optimal parameters for the c173 through trial sieving, but that is a low priority.

I have a request in to [B]debrouxl[/B] to see if they want to perform the sieving. The post-processing would still be up for grabs.

EdH 2013-09-20 11:46

c162 plus
 
[QUOTE=RichD;353531]I'm trying to get the optimal parameters for the c173 through trial sieving, but that is a low priority.

I have a request in to [B]debrouxl[/B] to see if they want to perform the sieving. The post-processing would still be up for grabs.[/QUOTE]
Is anyone else interested in 4788 anymore? I probably don't have the memory for it and couldn't take on anything too long within the next couple weeks.

1240@2e8 (c162 total), so far...

RichD 2013-09-20 16:16

A similar argument could be stated about Seq 3366. :smile:

LaurV 2013-09-20 17:38

[QUOTE=RichD;353605]A similar argument could be stated about Seq 3366. :smile:[/QUOTE]
Actually not, unless it gets a 5, it can lose the 3^2. The only problem is the size of the cofactor :razz:
4788 has a driver which is very difficult to get rid of, and at that size...
The two situations are very different.

schickel 2013-09-20 18:13

[QUOTE=EdH;353572]Is anyone else interested in 4788 anymore? I probably don't have the memory for it and couldn't take on anything too long within the next couple weeks.[/QUOTE]If we do decide to do the c173 on 4788, I can do the post-processing.

debrouxl 2013-09-20 18:46

Even if I once unleashed a C172 GNFS onto RSALS clients (shortly before shutting the grid down, in order to try and match the computing power explosion from ~300 GFLOPS to 2+ TFLOPS resulting from the announcement...), a C173 is significantly outside of the 14e comfort zone.
You'd have to ask Greg for sieving with 15e on NFS@Home :smile:

EdH 2013-09-21 00:54

c162
 
Just crossing 2100@2e8 (total)...

RichD 2013-09-21 05:18

In summary:
c162 (Seq 3408)
c172 (Seq 3366)
c173 (Seq 4788)

By no means do I own any of these sequences, they belong to the forum. So majority rules.

Since NFS@Home has agreed to help with c162, I think it would be best to turn it over to them. Let them sieve the entire range.

The c173 will be a long project so nobody gets burnt out sieving the c162. I see this as people may come and go, run a few million Qs, post it and come back later for more. An administrative nightmare - not really, just involved.

The c172 is weeks/months if not more away from NFS, and an ECM factor could still pop out. I would hate to have two team sieve projects going on at the same time. It would most likely be me that accumulated a bunch of rels on the wrong poly, the wrong range or the wrong number. Arg!

Comments?

EdH 2013-09-21 12:15

[QUOTE=RichD;353682]In summary:
c162 (Seq 3408)
c172 (Seq 3366)
c173 (Seq 4788)

By no means do I own any of these sequences, they belong to the forum. So majority rules.

Since NFS@Home has agreed to help with c162, I think it would be best to turn it over to them. Let them sieve the entire range.

The c173 will be a long project so nobody gets burnt out sieving the c162. I see this as people may come and go, run a few million Qs, post it and come back later for more. An administrative nightmare - not really, just involved.

The c172 is weeks/months if not more away from NFS, and an ECM factor could still pop out. I would hate to have two team sieve projects going on at the same time. It would most likely be me that accumulated a bunch of rels on the wrong poly, the wrong range or the wrong number. Arg!

Comments?[/QUOTE]If NFS@Home has the c162, then I will turn my ecm efforts toward the c172. I'll probably run 2000@11e7 and then see what happens with continuous 2e8, unless my machines whine too much about the size. I'll see how they do...

My final count for the c162 is ~2630@2e8 (total)

henryzz 2013-09-21 12:25

[QUOTE=EdH;353693]If NFS@Home has the c162, then I will turn my ecm efforts toward the c172. I'll probably run 2000@11e7 and then see what happens with continuous 2e8, unless my machines whine too much about the size. I'll see how they do...

My final count for the c162 is ~2630@2e8 (total)[/QUOTE]
What sort or range of memory per core do you have? It might be worth adding -maxmem to every call of ecm.py. It will slow it down a bit on your better machines but at least a higher bound should work on all your pcs.

RichD 2013-09-21 16:44

The c162 poly is still being researched. NFS@Home will get it in a few days.

EdH 2013-09-21 20:05

[QUOTE=henryzz;353694]What sort or range of memory per core do you have? It might be worth adding -maxmem to every call of ecm.py. It will slow it down a bit on your better machines but at least a higher bound should work on all your pcs.[/QUOTE]
I've got quite an array of cores/memory from 32-bit 750M through 64-bit quad core/4G. Currently I have one machine creating the command line and assigning the values. When I get a few minutes, I'm going to change the scripts so each machine can add its own options before calling the command line. It should be just as easy as adding -maxmem to the end of the current line for each machine's script.

What's a good rule for -maxmem? what the OS says is available or what the total size is?

EdH 2013-09-21 20:07

[QUOTE=RichD;353710]The c162 poly is still being researched. NFS@Home will get it in a few days.[/QUOTE]
I've moved all my ecm over to the c172, although I could move it back, if that would be any better. I suppose at this point we're looking for some good size factors for both of the numbers...

VBCurtis 2013-09-21 23:48

The 162 has had more-than-optimal ECM, no need to continue. The extra 2000 at 2e8 was polite, imo, when using external NFS resources.

The GPUers should give 5-7 days each (3 of us searching, so 15-20 GPU-days in total) in poly search, so we should have a poly Thursday or Friday.

We'd expect the C172 to take about 4x as long to NFS, so it demands roughly 4x as much ECM as the 162? Something like 15k curves at 11e7 and 20-25k at 2e8/26e7? If this is a decent estimate, no wonder you say weeks to months of ECM before this one is ready.

VBCurtis 2013-09-30 00:57

Line 1361 is now in factordb. Who picks it up next?

EdH 2013-09-30 01:54

[QUOTE=VBCurtis;354545]Line 1361 is now in factordb. Who picks it up next?[/QUOTE]
Thanks much! I think it's kind of a free-for-all now with ECM and if anyone has any success, it's mentioned so those working on it know. Someone else can chime in if there's more to it than that...

Again, thanks!

edit: i1362 is now a c125...

LaurV 2013-09-30 07:21

I didn't do any work for 3408 (neither 4788, shame on me!) but I am watching all three sequences very close (including 3366 which was somehow "my pick"). This one is easy now, but it regained the driver, so....

I think I will not get too many boulders onto my head if I would suggest to abandon it when it gets the next, higher (say C150), gnfs-able cofactor, and concentrate on 3366?

:leaving:

henryzz 2013-09-30 10:44

[QUOTE=LaurV;354573]I didn't do any work for 3408 (neither 4788, shame on me!) but I am watching all three sequences very close (including 3366 which was somehow "my pick"). This one is easy now, but it regained the driver, so....

I think I will not get too many boulders onto my head if I would suggest to abandon it when it gets the next, higher (say C150), gnfs-able cofactor, and concentrate on 3366?

:leaving:[/QUOTE]
Now the power of 3 has dropped I would agree with that.


All times are UTC. The time now is 15:39.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.