And as I mentioned above, it's easy to use a single ecmclient.cfg file for all instances; it saves the need to edit four files to perform the same change on all four files (for instance, changing the server all four clients are interacting with) :smile:

Thank you Paul. In the morning I managed with Paul Underwood's help to compile ecmclient, install g++, etc. I had a functional client, I crunched a few curves but here in Brazil I can't run all 4 cores, maybe I'll let only one without being worried to see my laptop burned.

Carlos

[QUOTE=ET_;325495]...and to set up the correct IP of the server, maybe?

Luigi[/QUOTE]Good catch!

The IP address does indeed need setting up to use 83.217.167.177 and not my internal network address.

Thanks.

Sources are here: [url]http://home.roadrunner.com/~mrodenkirch/home/ECMNet.html[/url]
yoyo

Paul, one core pointed to your server. Can't had more due to heat issues.

Carlos

Was about to lunch and this popped out while I as looking at the ecmclient terminal window...heheh. Only one core running!

[code][2013-01-24 14:39:19 GMT] a: Factor found! GC_5_708_C455 / (probable) 1334572628569379080920906080959483501 B1: 3000000 sigma: 1 (found in step 2)
[2013-01-24 14:39:19 GMT] a: Co-factor: GC_5_708_C455 / (Composite) 31422325912290301347105148262278127314637380593847903746739102288400255136836720732000803876790818924263329592300648839585632575083877559314729579728023605943583349819537952750504070194340502295801099698694132371826159231866912679869817241658498558253796803431426050577258290996521079326375526896601392445958089615898938994868634542098446799630267116610368831720633435620377834684428565767341254063431104873073820843281[/code]

[QUOTE=pinhodecarlos;325670]Was about to lunch and this popped out while I as looking at the ecmclient terminal window...heheh. Only one core running!

[code][2013-01-24 14:39:19 GMT] a: Factor found! GC_5_708_C455 / (probable) 1334572628569379080920906080959483501 B1: 3000000 sigma: 1 (found in step 2)
[2013-01-24 14:39:19 GMT] a: Co-factor: GC_5_708_C455 / (Composite) 31422325912290301347105148262278127314637380593847903746739102288400255136836720732000803876790818924263329592300648839585632575083877559314729579728023605943583349819537952750504070194340502295801099698694132371826159231866912679869817241658498558253796803431426050577258290996521079326375526896601392445958089615898938994868634542098446799630267116610368831720633435620377834684428565767341254063431104873073820843281[/code][/QUOTE]Yup, you got lucky!

Thanks for the factor,

Paul

[CODE][2013-01-24 14:39:19 GMT] a: Factor found! GC_5_708_C455 / (probable) 1334572628569379080920906080959483501 B1: 3000000 sigma: 1 (found in step 2)[/CODE]Seems that ecmclient stumbles over the changed output format of the new gmp-ecm 7.0-dev versions.

[CODE]Using B1=3000000, B2=5706890290, polynomial Dickson(6), sigma=1:3670404171[/CODE]

Update 20130303
 

I've been rather remiss at posting updates to the forum recently. The[URL="http://www.leyland.vispa.com/numth/factorization/cullen_woodall/cw.html"] web pages[/URL] have been kept reasonably current though. About all I can offer is that I've been rather distracted of late.

Anyway, since my last posting on 13 January a total of 140 factors have been reported to me! This astounding total, at least twice what might have been expected, is largely due to Rob Hooft running ECM in the idle time of a large number of systems. He reported three more factors today alone and has found 58 in the last five weeks.

Another major reason for the increased productivity comes from returning the ECMNET server at 83.217.167.177:8194 to the low-B1 candidates as mentioned in my previous updates.

To borrow a phrase: Keep the factors coming!


Paul

Update 20130417
 

Two main items of news recently. Because yoyo@home has been running ECM curves a long-standing target of reducing the number of C10xx candidates to below a hundred has been achieved. It was a close run thing in that the final factor came from the final candidate after over 80% of the curves had been run. Yoyo has now switched to running p50 trials on composites in the range C170-C199 with the aim of producing either complete factorizations or easy GNFS targets. There has been some success in that a c136 is in progress here and a c139 is in the queue. Reserve it quickly if you want it.

The other news is that the final sub-C150 (excepting the runts found in the last few days of course) finally succumbed to GNFS. The factorization was an ordeal :sad. With only 20 hours still to go with msieve's block Lanczos the machine's disk died. It turned out to be permanent death. Backups existed but didn't contain enough data to be worth trying to continue· Two more disks were purchased, set up as a mirrored pair[sup]*[/sup] and the machine completely rebult --- as a Gentoo box this time. It also seemed like a good idea to evaluate CADO-NFS.

I was expecting teething troubles with the new software and, sure enough, they happened. Most arose from my incompetence[sup]*[/sup] but two from a couple of bugs in CADO-NFS.One bug wiped all the relations that I'd collected after 24 hours work. Backups were about 12 hours old so I restarted yet again. Eventually the C147 split as p72 * p75 so at least it wasn't an ECM miss.

First reactions to CADO-NFS: it's a solid implementation as long as you avoid the bugs and easy to use. The polynomial finder is very good and the siever is much easier to run over several machines than is msieve. The siever feels to be markedly slower and the block Wiedemann is also slower than msieve's block Lanczos. I've not made objective measurements of either component but a guess is around a factor of 1.5 to 2 times. The c137 runt was started with CADO-NFS yesterday.

Paul

* A sign of intelligence is said to be the ability to recognize a mistake the second time you make it..

Is the server down?