Thanks! I'll play with parameters and test-sieving this weekend. That's exactly what I was looking for.

(7+3_320)
 

C146 cofactor of 7^320+3^320
factors as:
[code]67927455718198283636176484354385744910102330009568394787201
149835959796840893864901412996722137788935475049509309358722225494196555408180318836481
[/code]using CADO-NFS on a Dual Xeon E5-2650 for a couple of days.

[QUOTE=VBCurtis;501224]Thanks! I'll play with parameters and test-sieving this weekend. That's exactly what I was looking for.[/QUOTE]

14e/31LP, -a side sieving, alim=rlim=33.5M produced output in a typical range (yield just over 2, sec/rel faster with these small lim's than with 67M on R side alone or both sides). I expect to sieve Q from 6M to ~75M.

I have the job running 6-threaded on a 6-core i7 already running 5xLLR; it'll take about 3 weeks. That's roughly the time a GNFS-159 would take, so SNFS-octic-175 is about 4 times faster than GNFS on the 169-digit cofactor would be.

[QUOTE=VBCurtis;501462]14e/31LP, -a side sieving, alim=rlim=33.5M produced output in a typical range (yield just over 2, sec/rel faster with these small lim's than with 67M on R side alone or both sides). I expect to sieve Q from 6M to ~75M.

I have the job running 6-threaded on a 6-core i7 already running 5xLLR; it'll take about 3 weeks. That's roughly the time a GNFS-159 would take, so SNFS-octic-175 is about 4 times faster than GNFS on the 169-digit cofactor would be.[/QUOTE]

This is very useful information about sieving with octics. Thanks for reporting back.

Here is another update. The following are the factors reported to me after the last update, on November 25, and through November 29. The website has been updated with all of this information, as have the ECMnet server and the reservation service. The latter two have already received new factors since November 29, which will appear in the next update.

Note that several factors have been found by ECM with digit counts in the mid-40s, which has a couple of implications: 1) It is still possible to find factors with relatively little work, and 2) if you reserve a number to factor with NFS, it's probably worth doing a little bit of ECM pre-testing on it first.

As of this update, there are 1543 remaining composites in the tables.

[code]
7+2 310 C200 29134931330309568622103968590078395459674981. C156 Yoyo@home ECM 2018-11-26
7+3 310 C203 598472194454145810791374307259248817401571536826721. C153 Yoyo@home ECM 2018-11-26
4+3 430 C190 2229977176585304380126731403691264471606410841587090556579661968447464401581. P115 NFS@Home & C Pinho SNFS 2018-11-26
9-8 293 C191 723145398456951021234124546371594856132040287. C146 J Becker ECM 2018-11-26
3-2 553 C186 5878835902694438711232695492067440867713869282016421929. P132 NFS@Home & C Pinho SNFS 2018-11-27
9+2 642L C174 4763958967873367046955107358012058628975182025840010625988089100689827917953392393. P92 T Womack SNFS 2018-11-27
4+3 1179M C228 29362818556358856328925701147565530984150191644710917015380500680509412691563331851375698719296383944756406341. P118 NFS@Home & D Domanov SNFS 2018-11-28
[/code]

[QUOTE=VBCurtis;501462]14e/31LP, -a side sieving, alim=rlim=33.5M produced output in a typical range (yield just over 2, sec/rel faster with these small lim's than with 67M on R side alone or both sides). I expect to sieve Q from 6M to ~75M.

I have the job running 6-threaded on a 6-core i7 already running 5xLLR; it'll take about 3 weeks. That's roughly the time a GNFS-159 would take, so SNFS-octic-175 is about 4 times faster than GNFS on the 169-digit cofactor would be.[/QUOTE]

I have no idea why my test-sieve results were so wrong, but after letting this job run from Q=5.5M to 19M, I have just over 16M relations. That implies a sieve range of something like 5.5 to 140M, not tenable with alim and rlim of 33.5M.

I've restarted the job with alim=rlim=134M, and 32LP. I'll let it run a day or two and compare to previous GNFS-170ish results to see if this octic is usable over a GNFS-169 job.

I also tried continuing the job with 15e rather than 14e, but the same parameters. sec/rel more than doubled, while yield only increased to 1.4 (sample size 6x1k blocks while running factmsieve.py).

My test-sieving covered 1k blocks for half a dozen Q's spread out every ~10M from 8M to 80M, similar to what I usually do. I'm perplexed at this job!

[QUOTE=VBCurtis;501717]I have no idea why my test-sieve results were so wrong, but after letting this job run from Q=5.5M to 19M, I have just over 16M relations. That implies a sieve range of something like 5.5 to 140M, not tenable with alim and rlim of 33.5M.

I've restarted the job with alim=rlim=134M, and 32LP. I'll let it run a day or two and compare to previous GNFS-170ish results to see if this octic is usable over a GNFS-169 job.

I also tried continuing the job with 15e rather than 14e, but the same parameters. sec/rel more than doubled, while yield only increased to 1.4 (sample size 6x1k blocks while running factmsieve.py).

My test-sieving covered 1k blocks for half a dozen Q's spread out every ~10M from 8M to 80M, similar to what I usually do. I'm perplexed at this job![/QUOTE]

Could you be running into similar issues to [url]https://mersenneforum.org/showthread.php?p=335882[/url]

11^275+7^275 C138 factored
 

[B]11^275+7^275 C138 cofactor[/B]
[code]215290482711498775857088271400131320612386268382231605142383940593392584190741166564737484238337228384236630964779465097892248827664917851[/code]factors as:
[code]769488969375648107454325012985724492433629702550798762063554301
279783715270385575493842065372546994941075034967188989299578239204825098551[/code]with CADO-NFS in about 1.1M threadseconds

11^275-3^275 factored
 

11^275-3^275 cofactor C138:
[code]241481114627197655636802482519133477747496502185637414625282276645257607743867204318972229839736875975257161324043742089143818591829941851[/code]
factors as:
[code]
15648945542413790506692686405071747793299998966299058674551
15431142882611764104799599868091290208101320825352712829426141652166746229802301[/code]

9^309+8^309 factored
 

C138 cofactor of 9^309+8^309:

[CODE]prp50 = 21390575396786807527427938316788563378837175111963
prp87 = 546813687095488247919565776474836286417700363251587105783514743124253662225974433054361[/CODE]

Thanks very much to jyb and RichD for helping me learn how to find the SNFS poly.

7-4_363
[CODE]prp51 = 116130016461076358928258030747660632445330488879047
prp75 = 189357921726768473176299533767403621078151712802326821469437589347998318431
[/CODE]
5-4_755L
[CODE]prp74 = 78309889959047816864609410444547746953366914584525493299091945867833525691
prp51 = 326314837717229390627350996286816552471339095832051
[/CODE]