VBCurtis,

I'm having a trouble I think I had before: My system is crashing during polyselect - the host is hanging up. The composite is a C139, so CADO-NFS is using params.c140. Do you have a modified c140 I should try before I do something with the default one?

Ed

Ed-
RichD and I have been working on params for c140 and c145.
Attached is the fastest c140 file we've yet run; I'm almost ready to post it "officially", but I want to test a few more inputs to make sure I didn't just get a lucky poly on this run.

I think the hang happens on very small c5 values; we worked around it by using a small admin value such as tasks.polyselect.admin = 1680 (used in this file, in fact).

Note the file has an input and name and number of clients for Rich's 4-core i5; you should reset the top section to what you normally use.

Edit: may as well include timing data: On a non-HT i5-quad-core desktop, 16k thread-sec poly select, 195k thread-sec sieve, 29k thread-sec matrix. Wall clock time 112k sec, 31 hrs and change.

Thanks Curtis,

I'll try to run this tomorrow. I did remove the RichD specific lines.

-Ed

Just an update. The original c139 that I mentioned above would not factor with cado-nfs. The host kept crashing.

I tried a different set of composites and all ran fine. I then put the original c139 back in the queue and ECM factored it while I wasn't looking.

I haven't bothered finding and reconstructing the c139, but several other composites have been using the modified params.c140 file without issue.

I will try to get some details up soon.

Thanks!

I'm running a c150 by myself (e.g. ./cado-nfs.py <BIG_NUMBER> --screenlog DEBUG --filelog DEBUG), I'm not seeing datetime/timestamps in my log files.

In VBCurtis's coordinated Team CADO solve of 2,2330L all the log files have both PID and datetime.

What option(s) do I set to get datetime in my logs?

The only option I set for CADO jobs is --server-threads, if I didn't set it in the params file.
Maybe try ditching the DEBUG flags?

Every so often I am getting an error for full buckets while sieving. Is there an easy fix for this?

@VBCurtis:

I modified the "improved" params.c140 into a "modified" params.c150 (although I forgot to rename it within the file) based on your suggestions in the "Improved" thread and am running it on another c152 composite. I hadn't noticed this before, but maybe it's normal behavior: after settling with receipt of several WUs from many clients, it gave an ETA of ~7 PM. Later on a check showed an ETA of ~7:30 and then it kept moving later. I then started up a few more clients and even after they had submitted several WUs, the march into the future continues. At present, the original ETA of ~7 PM has transformed into later than 9:30 PM. I can foresee it as an elusive goal.

I assume (I know!) this is because of diminishing relations as the search area progresses, but thought I'd offer this bit of info in case it is helpful in reaching better parameters.

-Ed

[QUOTE=EdH;526939]@VBCurtis:

I modified the "improved" params.c140 into a "modified" params.c150 (although I forgot to rename it within the file) based on your suggestions in the "Improved" thread and am running it on another c152 composite. I hadn't noticed this before, but maybe it's normal behavior: after settling with receipt of several WUs from many clients, it gave an ETA of ~7 PM. Later on a check showed an ETA of ~7:30 and then it kept moving later. I then started up a few more clients and even after they had submitted several WUs, the march into the future continues. At present, the original ETA of ~7 PM has transformed into later than 9:30 PM. I can foresee it as an elusive goal.

I assume (I know!) this is because of diminishing relations as the search area progresses, but thought I'd offer this bit of info in case it is helpful in reaching better parameters.

-Ed[/QUOTE]

I've noticed it too when I did some stand-alone (single box) jobs for VBCurtis. The ETA on sieving perpetually increases, most likely from what you mentioned above.

[QUOTE=RichD;526941]I've noticed it too when I did some stand-alone (single box) jobs for VBCurtis. The ETA on sieving perpetually increases, most likely from what you mentioned above.[/QUOTE]I was somewhat disappointed that adding several more totally unique clients did not seem to offset the increasing loss.

[QUOTE=EdH;526942]I was somewhat disappointed that adding several more totally unique clients did not seem to offset the increasing loss.[/QUOTE]

I can't think of a reason except that the first few WUs being returned may have a temporary reverse in ETA. After that is established you would have a constant flow of WUs with each being fewer relations [strike]as[/strike] than before.