Now what (VI)
 

OK, it is possible to factor a 197-digit general number using the current tools and fifty CPU-years of sieving time on Bruce's cluster. Good.

My inclination is to do 2^1009-1 next. It's 204 digits and SNFS difficulty 304, so it may be that after a CPU-year of polynomial selection it turns out to be easier by SNFS; but a CPU-year of polynomial selection is not a disastrous amount of time to waste.

I'm slightly saddened how little external interest I had in the 197-digit GNFS sieving - maybe I over-egged the description of how difficult the sieving would be to the point that it put people off, and likely the other people with significant resources (I'm thinking of Serge and Ben) have more interesting things to do with them.

I'm willing to help but I only have 4 cores and I am under windows. I know linux is faster on sieving...
For polynomial selection GPU is faster, right? So probably most of us are on windows without a good GPU card.

[QUOTE=fivemack;281834]I'm slightly saddened how little external interest I had in the 197-digit GNFS sieving - maybe I over-egged the description of how difficult the sieving would be to the point that it put people off, and likely the other people with significant resources (I'm thinking of Serge and Ben) have more interesting things to do with them.[/QUOTE]

If your phrase "external interest means "interest of people here to join factoring" here, this could have some of the following reasons:

* There is a nasty not-yet-resolved crash bug (possibly somehow related to [URL="http://www.mersenneforum.org/showthread.php?t=14812"]this one[/URL]?) in the windows binaries of GGNFS, which happens especially with the 15e (and maybe 16e) sievers (it also happens occasionally with the 11e and 12 sievers, but *very* seldom with 13e and 14e). So, when having a sufficiently fast PC (e.g. an Intel i5 or i7), but running windows, people will keep finding one or more threads sitting idle with error messageboxes on the screen, when coming back from work or getting up in the morning - at least this happened to me.
* The aliquot project seems to have grown in the meantime, tying up people's resources with aliquot sequences. And I don't mean just IGG-type stuff, but also bigger factorizations: The c155 to c16x team factorizations which keep popping up there are far less prone to trigger the ggnfs crash bug on windows systems.
*(Probably just a very minor reason: Unlike your previous threads, the thread title ("G197") was a bit... erm... "what's that?": OK, for you it is clear at the first glance, that this means "gnfs-197", but for others? Maybe something like "Team sieve: GNFS-197 from <number>" would have been a bit more appealing. (Or, like your previous factoring threads: something like "poly search for..." and then change to "sieving..."))

I am sorry to report don't really have significant resources. (I had borged some two or three years ago, but that all ended abruptly with "a sound of a breaking string dying away sadly", as in Chekhov's Cherry Orchard.)

Then, I only had a mulitple-personality-disordered Phenom that started life as a 940 4-core with 8Gb of DDR2 memory, then I'd replaced its brain with a 1055T (and had shelved the 940) and just two monts ago dissected its personalities into two boxes: restored the 4-core and gave the 6-core 16Gb of DDR3 memory... but that's it, that's the 10 cores I have. :sigh:

[QUOTE=fivemack;281834]My inclination is to do 2^1009-1 next. It's 204 digits and SNFS difficulty 304, so it may be that after a CPU-year of polynomial selection it turns out to be easier by SNFS; but a CPU-year of polynomial selection is not a disastrous amount of time to waste.[/QUOTE]
M1009 indeed could turn out to be snfs.
There's a definite gnfs
204 3 748 + 324.4 0.65
but it probably needs more ECM. Or there's
206 2 2218 M 333.8 0.615 /gnfs
That's a tall order for sure.

As it happens, I now have access to even more horsepower (~ 120 X5687 cores + the 60 X5570 cores I already had access to). The new gear is all other people's workstations and the rest of it is a shared resource - so all of it can only be used part time (non office hours). This means that it's more manual effort on my part to daily re-start jobs. This last chore is largely why I didn't participate in the last job...

I've thought of using daily recurring scheduled tasks for the 120 windows cores, but haven't implemented it yet. I'm sure there's a way to schedule jobs on linux too but I don't know the particulars.

If my babysitting time could be reduced, I would definitely participate in the next job.

[QUOTE=Batalov;281843]M1009 indeed could turn out to be snfs. [/QUOTE]
There's a minor annoyance about M1009 in the epfl counts. It was left off
of the June version of the epfl report; presumably as it wasn't an attractive
candidate for large snfs. The subsequent/final version of the epfl report
gives a range of M values where they ran ecm (to t65 or 2t65, depending
on size, split at M1125, iirc), but PaulZ subsequently found a small factor
from M1115 that they couldn't possibly have missed with t65. I got no
reply from an email request for clarification that included our friends
Thorsten and Joppe (in a cc: on a reply to PaulZ's factor report). I haven't
been running either 2- or 2+ numbers since then, and my curve count on
M1009 is below 2t55. Perhaps a direct inquiry regarding M1009 would help.
[QUOTE=Batalov;281843]
There's a definite gnfs
204 3 748 + 324.4 0.65
but it probably needs more ECM. Or there's
206 2 2218 M 333.8 0.615 /gnfs
That's a tall order for sure.[/QUOTE]
Another problem with ecm pretests on 3p748; it's just been added
to the regular tables this week, and curve counts are mostly whatever
Sam and PaulZ may have run (quite likely substantial, judging by factor
sizes they found during testing on the extension). This could be fixed
during poln selection (in parallel). Uhm, well. Suppose sorting sieving
candidates shows how reliable curve count ranges are (depending,
perhaps, on whose they are). The 2M2218 C206 is someone's cofactor
from an earlier C262, and doesn't appear to have been run at all on our
pc/grid. It did make the new 8-core cluster input file though. The
count there (non-first holes, not 2- or 2+, C20x's) is 24119 curves
with B1=900M, where t60 = 13061. That's c. 1.8t60, on a file that
initially had 11 numbers and has just five left, with a p65 found. (That's
c. to the nearest t55 = c. 2700 curves, 9/5.)

On the topic of attracting a larger pool of forum contributors, I wonder
whether a warmup gnfs191, one of 2M2090 or 2M2110 perhaps is a
possibility? We'd get a chance to try the new poly select, and might hope
to do better than what we had for gnfs187? These are at 17644/13061
with an extra 3t55, resp 2t55, from the pc/grid. That's 9/10, resp 8/10,
of 2t60. Well, I'll stop clogging bandwidth; the matrix for the gnfs167
cofactor of 3p608 just finished. -Bruce

RSA-210 and RSA-704 ? :smile:
(yeah, according to the rules of thumb, these are more than twice harder than a GNFS 204, and close to M1061, so they may be a bit tall for now...)

[quote=bsquared]I've thought of using daily recurring scheduled tasks for the 120 windows cores, but haven't implemented it yet. I'm sure there's a way to schedule jobs on linux too but I don't know the particulars.[/quote]
cron/anacron does the job on *nix, and can launch any executable (so native code, BASH, Perl, PHP, Python, whatever).
RSALS uses cron to trigger PHP scripts (made mainly by squalyl) every few minutes for automatic work generation and for concatenating gzipped results to the large files containing raw relations.

Note that once it's set up, BOINC is a rather easy way to babysit a group of computers :smile:
It takes me 10-15 minutes to build a .poly for a number (usually from William Lipp's lists), make a short test sieving run at (r|a)lim/2 (during which I usually do something else), create and fill an entry into the automatic work generation system, and move the number from "queued for sieving" to "sieving" state.
But now that, thanks to frmky, I've been able to make sense of BOINC WU priorities, I could even put many numbers in "sieving" state, and, actually, do largely without the automatic work generation infrastructure (like I did in the beginning, and like frmky does for NFS@Home).

In case you didn't notice the topic here ( [url]http://www.mersenneforum.org/showthread.php?t=16114[/url] ), [url]https://github.com/GDSSecurity/cloud-and-control[/url] could be an interesting starting point, should you want to deploy a BOINC server to manage your own sieving :smile:

[QUOTE=debrouxl;281866]RSA-210 and RSA-704 ? :smile:
[/QUOTE]

I like the idea...

Note that if anyone wants to do numbers larger than ~GNFS200 in difficulty then we should invest some development effort in getting the sieving tools to handle large primes bigger than 33 bits in size. Though pretty soon we'll be reaching the 2^32 relation limit in Msieve, since 2,1031- already needed 2^30 relations after duplicates were removed manually.

So, we will need a new implementation/algorithm/code? I'm nowhere near as being qualified to do that.