I'm getting a really poor relations ratio. I'm seeing less than 85k relations per 100k q. Is this a sign of a poor polynomial, or does this just happen sometimes?

I had one machine working the polynomial while my main one is running the ECM and now that I have a candidate, I have several machines running with it while the main one finishes ECM. At this point, would a restart with a better poly make a big enough difference to warrant running a few more hours of selection?

Here's a bit of the log:
[code]
Sat Dec 29 10:27:50 2012 expecting poly E from 2.16e-11 to > 2.49e-11
Sat Dec 29 10:27:50 2012 searching leading coefficients from 1 to 2846669
Sat Dec 29 15:27:48 2012 polynomial selection complete
Sat Dec 29 15:27:48 2012 R0: -1728427528919286628495180538
Sat Dec 29 15:27:48 2012 R1: 30361745983217
Sat Dec 29 15:27:48 2012 A0: 27794688864805293268138545836950245
Sat Dec 29 15:27:48 2012 A1: 41756348327044212147658721274
Sat Dec 29 15:27:48 2012 A2: -54605224849948984856272
Sat Dec 29 15:27:48 2012 A3: -24857135575026902
Sat Dec 29 15:27:48 2012 A4: 5603890979
Sat Dec 29 15:27:48 2012 A5: 276
Sat Dec 29 15:27:48 2012 skew 3199130.95, size 2.219e-13, alpha -5.811, combined = 2.596e-11 rroots = 5
[/code]

I'll run some GPU stage 1. Do you know how many hits you got in those five hours?

Edit: Perhaps the ggnfs parameters are off?

Edit2: YAFU (it's probably msieve's data) suggests around 50 CPU hours of poly select, so unless you were running 8 cores or something, that's probably a woefully bad poly. How many core hours total did you run?

[QUOTE=Dubslow;323082]I'll run some GPU stage 1. Do you know how many hits you got in those five hours?

Edit: Perhaps the ggnfs parameters are off?

Edit2: YAFU (it's probably msieve's data) suggests around 50 CPU hours of poly select, so unless you were running 8 cores or something, that's probably a woefully bad poly. How many core hours total did you run?[/QUOTE]
Thanks!

It had suggested 54.59 CPU-hours, but I had factmsieve.py set with a wall time of 5 hours with dual core, so it was definitely cut prematurely. The question would be the difference in working with a poor poly that was obtained at 5 hours vs. a better poly that took 30 hours. At a total of 50 hours estimate for sieving, I'm not sure if a better poly would have made it faster overall.

There are 4985 polynomials in the test.dat.p file.

Over the last five hours I've accumulated >2.5M relations across all my machines with this poly, so I should be able to reach the 22M requested in roughly 45 more hours. Unless restarting with a better poly would make up the difference, it probably isn't worth restarting for this size composite. But, for something larger, I should try to be more particular in my poly choice, I suppose.

Edit: Don't tie up your systems for this. I'll get along with what I have here. I was just wondering...

[QUOTE=EdH;323083]
Edit: Don't tie up your systems for this. I'll get along with what I have here. I was just wondering...[/QUOTE]

I got 2.4 million stage 1 hits in 45 minutes, size opt running now, will have (probably a significantly better) poly sometime in the next hour or two. :smile:

[QUOTE=Dubslow;323084]I got 2.4 million stage 1 hits in 45 minutes, size opt running now, will have (probably a significantly better) poly sometime in the next hour or two. :smile:[/QUOTE]
I'm not sure it would benefit me to start over at this point, but I would like to compare the results between our two poly's on a couple of my machines...

Holy [i]bejeesus[/i], root opt takes forever. Out of the 2.4M hits I got 860K size opt polys (took about an hour on cpu vs 45 minutes for stage 1 on gpu). I sorted them and am running root opt on the best 86K of them; 2+ hours in and I have 12.7K root opt-ed polys, so who knows how long it'll take. I'll post the best in the morning, but in the meantime, there's probably no way it'll be advantageous to switch.

You're processing too many size optimized polys, only 1-2% of them are useful :wink:
And using the out-of-tree MPI patch makes root opt scale near-linearly with the number of cores.

[QUOTE=debrouxl;323091]You're processing too many size optimized polys, only 1-2% of them are useful :wink:
And using the out-of-tree MPI patch makes root opt scale near-linearly with the number of cores.[/QUOTE]

Ah crap, now I know for next time. Those 10% took 19 hours :razz:

[code]polynomial selection complete
R0: -1275730550910569740948790967
R1: 68465311488443
A0: -602386029120087908552165345576724184
A1: 511077501414883308580053270504
A2: 163159912488603352570952
A3: -74272054904151261
A4: -11596854544
A5: 1260
skew 4253756.85, size 2.156e-13, alpha -7.219, combined = 2.577e-11 rroots = 5
elapsed time 19:32:47[/code]

I'm not exactly sure how to get second or third place poly easily, since it's more than one line per poly.

Edit: And it's not even as good as the first one :razz: :razz: (Edit2: Since the first one sieves so poorly, maybe this one sieves better despite the scores)

I will have to test your poly for a comparison on one of my machines, but I'm going to wait until the current operation is completed.

Thanks for the extra work you did.

LA says a few more hours...

I compared the two polynomials by running them side by side in one of my dual core machines:

My poly - Total time: 9:38:09 - Total yield: 463002

Dubslow's poly - Total time: 9:46:48 - Total yield: 529197

Would there have been any appreciable affect on the LA stage between the different sets of relations?

OK, looks like that one finished and now I'm running a c106 that should be done soon...