Based upon the log it looks like that may have fitted on 4gb. I think I am now set up with a new pc able to do a 16GB job. It isn't on 24/7 though so I would prefer to do a job that isn't more than about half a week. This would have been an ideal test.

[QUOTE=henryzz;444815]Based upon the log it looks like that may have fitted on 4gb. I think I am now set up with a new pc able to do a 16GB job. It isn't on 24/7 though so I would prefer to do a job that isn't more than about half a week. This would have been an ideal test.[/QUOTE]

Real value of memory used was 3.8 GB instead on the one presented on the log file.

Excellent, Carlos,

That's a good split. I'm glad it didn't turn out to have a small factor my ECMing should have found.

Now it looks like another c162 has shown up, but it could be worse...

Ed

Note: I have two 4GB, core 2 quad machines that both said they could solve the LA. I could look up the values, but they also both said about 78 hours, I think. The odd part is that I set them up to use mpi and they came back at ~275 hours to solve. My three, 4gb dual core machines were 30 something hours. The quad cores are, unfortunately, on a 10/100 switch, while the three duals are on a Gigabit, currently.

I'll turn several machines loose on the new composite in a little bit...

[QUOTE=pinhodecarlos;444817]Real value of memory used was 3.8 GB instead on the one presented on the log file.[/QUOTE]

Quite an underestimate then.

EdH, just thought I would point out that you would save money by replacing your core 2 systems with more modern systems. You get much more efficiency with recent cpus. This would allow lower power consumption which would save you money in a year or two.
That is of course for the same performance.
Another benefit would be more memory.

[QUOTE=EdH;444824]Excellent, Carlos,

That's a good split. I'm glad it didn't turn out to have a small factor my ECMing should have found.

Now it looks like another c162 has shown up, but it could be worse...

Ed.[/QUOTE]

Someone posted a P48 for that C162, on line 1658 with a C187 presently. If no progress is made, I'll throw some t50-level curves at it tomorrow.

[QUOTE=VBCurtis;444829]Someone posted a P48 for that C162, on line 1658 with a C187 presently. If no progress is made, I'll throw some t50-level curves at it tomorrow.[/QUOTE]
One of my machines did that while I wasn't looking. I have a few working on the c187, but I won't be watching over them during the night. I don't know if they will get anywhere. Thanks.

[QUOTE=henryzz;444825]Quite an underestimate then.

EdH, just thought I would point out that you would save money by replacing your core 2 systems with more modern systems. You get much more efficiency with recent cpus. This would allow lower power consumption which would save you money in a year or two.
That is of course for the same performance.
Another benefit would be more memory.[/QUOTE]
Yeah, and I could probably afford the up front investment. But, in reality, I would get the new machine and then still run all these old ones, too. Most be an addiction... (I actually have several more old machines waiting for a chance to help.)

Edit: It's also an opportunity to play. One of the machines is running from an 8GB micro SDHC card. I also have a Raspberry Pi assigning some of the work.

How odd! I let about a dozen machines work on the c187 overnight and they returned nothing. This morning I set up a machine to run a distributed ECM effort and it immediately gave me this:
[code]
-> ___________________________________________________________________
-> | 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:
-> 2097073091591237404218687836513685895877817960290253421046297596274623117183515885512940927331281174454391017370699311839113500789090430626739805618613433715612809988590674625990004910081 (187 digits)
->=============================================================================
-> Working on number: 209707309159123740...674625990004910081 (187 digits)
-> Currently working on: job6427.txt
-> Starting 4 instances of GMP-ECM...
-> ./ecm -c 8 2000 < job6427.txt > job6427_t00.txt
-> ./ecm -c 8 2000 < job6427.txt > job6427_t01.txt
-> ./ecm -c 7 2000 < job6427.txt > job6427_t02.txt
-> ./ecm -c 7 2000 < job6427.txt > job6427_t03.txt

GMP-ECM 7.0.3 [configured with GMP 6.1.1, --enable-asm-redc] [ECM]
Using B1=2000, B2=147396, polynomial x^1, 4 threads
Done 29/30; avg s/curve: stg1 0.010s, stg2 0.012s; runtime: 1s

Run 29 out of 30:
Using B1=2000, B2=147396, polynomial x^1, sigma=1:2423212582
Step 1 took 8ms
Step 2 took 12ms
********** Factor found in step 1: [B]111817691327273[/B]
Found prime factor of 15 digits: 111817691327273
Composite cofactor 18754394467449971433169133636162492600298914413396595751836384412408176818652556808225119789256080647070289939738286246593531841108089813728776853478001495732073616829270297 has 173 digits

waiting...
-> ___________________________________________________________________
-> | 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:
-> 2097073091591237404218687836513685895877817960290253421046297596274623117183515885512940927331281174454391017370699311839113500789090430626739805618613433715612809988590674625990004910081 (187 digits)
->=============================================================================
-> Working on number: 209707309159123740...674625990004910081 (187 digits)
-> Currently working on: job1932.txt
-> Starting 4 instances of GMP-ECM...
-> ./ecm -c 19 11000 < job1932.txt > job1932_t00.txt
-> ./ecm -c 19 11000 < job1932.txt > job1932_t01.txt
-> ./ecm -c 18 11000 < job1932.txt > job1932_t02.txt
-> ./ecm -c 18 11000 < job1932.txt > job1932_t03.txt

GMP-ECM 7.0.3 [configured with GMP 6.1.1, --enable-asm-redc] [ECM]
Using B1=11000, B2=1873422, polynomial x^1, 4 threads
Done 6/74; avg s/curve: stg1 0.043s, stg2 0.046s; runtime: 1s

Run 6 out of 74:
Using B1=11000, B2=1873422, polynomial x^1, sigma=1:4277626488
Step 1 took 36ms
********** Factor found in step 2: [B]1095649678256579[/B]
Found prime factor of 16 digits: 1095649678256579
Composite cofactor 131954905347588391934699304738827948133275634558635457624548533060467418907362122329509131668522067078677069743086471484822031174847391546400311 has 144 digits

waiting...
-> ___________________________________________________________________
-> | 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:
-> 2097073091591237404218687836513685895877817960290253421046297596274623117183515885512940927331281174454391017370699311839113500789090430626739805618613433715612809988590674625990004910081 (187 digits)
->=============================================================================
-> Working on number: 209707309159123740...674625990004910081 (187 digits)
-> Currently working on: job9509.txt
-> Starting 4 instances of GMP-ECM...
-> ./ecm -c 27 50000 < job9509.txt > job9509_t00.txt
-> ./ecm -c 27 50000 < job9509.txt > job9509_t01.txt
-> ./ecm -c 27 50000 < job9509.txt > job9509_t02.txt
-> ./ecm -c 26 50000 < job9509.txt > job9509_t03.txt

GMP-ECM 7.0.3 [configured with GMP 6.1.1, --enable-asm-redc] [ECM]
Using B1=50000, B2=12746592, polynomial x^2, 4 threads
Done 2/107; avg s/curve: stg1 0.219s, stg2 0.190s; runtime: 1s

Run 2 out of 107:
Using B1=50000, B2=12746592, polynomial x^2, sigma=1:3797496244
Step 1 took 196ms
********** Factor found in step 2: [B]129719656920613[/B]
Found prime factor of 15 digits: 129719656920613
Composite cofactor 16166193631506619062699986973017125397615941076923986434223011454064246619826586744066970275619259028143877483718271885648417579265271700432201498195640573216055668220689837 has 173 digits
[/code]:smile:

I would double check what you did overnight.

[QUOTE=henryzz;444860]I would double check what you did overnight.[/QUOTE]
I am going to check more closely, because what I did was to set ali.pl loose on 3408 on nearly all of the 24/7 machines. They were busy running instances of YAFU against the c187 and were all on 2350 curves at 3e6 this morning, when I swapped them over to my distributed ECM scripts. My scripts allow me to choose a few less curves than (# of machines) * (YFAU's suggested curves). My scripts don't suto-send the factors to the db, though. That's why I used ali.pl overnight.

I'm going to reconstruct the exact composite and play with YAFU and ali.pl separately and see if I find something odd about them.

[QUOTE=EdH;444879]...
I'm going to reconstruct the exact composite and play with YAFU and ali.pl separately and see if I find something odd about them.[/QUOTE]
It was my mis-reading of the outputs! I really must take better looks at things.

Basically, YAFU was asked by ali.pl to factor a c187 and YAFU hadn't factored it [B]totally[/B], so it didn't report anything. Had I looked at more than just the left side of the output, showing the curves completed, I would have seen the cSIZE had changed, which is the only indication that a factor has been found. At that point it doesn't say that a factor has been found, or print the new factor. It might print those details if more verbosity is signaled.