GC_3_506 factors as:

[CODE]prp79 factor: 6688742297899204875322374265538672579514865892235600753677914269234448014753053
prp139 factor: 1861911271666653241702957318630794579144189108153339143646795162302908129437080678440534302552559816314796163641967314447270652784487170871[/CODE]

Took 127 hours with 4 threads at density of 128.

Wrong data for GC_7_282
 

The data for GC_7_282 is incorrect, the the GC_7_282.ini/poly on the downloadpage contain:
[code]
12453844677732040915111071175687067562410129112238964292270981600355884254591911155601284284678108776937882382785681108530493459564533106625950387656134046896020256487637498324279619079746225156159152409501017679919163[/code]Which according to the factordb = (3^506*506+1)/1076965918797073171981264625

The relations on the server are also for GC_3_506, since after 62 hours, msieve reported (I didn't notice it untill then), the prp79*prp139 (as previously reported by Ben).

[QUOTE=henryzz;386069]Msieve is very good at stress testing memory. It can find faults that other programs can't. It does sound like you have a hardware problem. Has this pc always done this or is it new? Does it need dedusting?[/QUOTE]
Yes, it's running a new 16GB memory kit (DDR3-2400), so I was suspecting that. I'll turn it down a notch to 2133 and see if the issue persists.

Is there a way we could be more careful?
 

For 14e jobs we've now had at least two instances of factoring the wrong number, at least one of putting through a number which had already been factored by ECM, and one where we were saved from factoring the wrong number only because we had the wrong polynomial and all the jobs on client machines crashed at start-up.

I also suspect that we're running 14e/31lp on jobs which would finish more quickly with 32lp or 15e.

I'm really not happy with the associated waste of time and, in the ultimate sense, of CO2 emissions from the coal burned to power the computers doing tens of thousands of CPU-hours of literally useless work.

[QUOTE=fivemack;386221]For 14e jobs we've now had at least two instances of factoring the wrong number, at least one of putting through a number which had already been factored by ECM, and one where we were saved from factoring the wrong number only because we had the wrong polynomial and all the jobs on client machines crashed at start-up.

I also suspect that we're running 14e/31lp on jobs which would finish more quickly with 32lp or 15e.

I'm really not happy with the associated waste of time and, in the ultimate sense, of CO2 emissions from the coal burned to power the computers doing tens of thousands of CPU-hours of literally useless work.[/QUOTE]Oh dear.

My role, so far, has to arrange ECM pre-testing of likely candidates (those not already reserved and within the correct range of SNF difficulties) and then submit the symbolic form of the candidates remaining to Lionel and Greg. After the ECMNET clients have done roughly half of the pretesting, Rob Hooft does the remainder with a little help from my GPU.

I have no control over how the NFS@Home datafiles are created and I've no input on which sieve parameters are chosen. So far only SNFS jobs have been requested but there are around 20 GNFS targets which are of comparable difficult to those run so far. It is not clear how I can increase the reliability of NFS@Home but if anyone has any suggestions I'll look into them.

Sneak preview: another 20 candidates will be turned over to Rob within a week. He will take them all up to a t55 or so by ECM by which time 19 will be ready for SNFS and a C156 for GNFS. Assuming he doesn't completely factor them of course.

A script to automatically check if the number is factored in factordb immediately before making WUs available to clients could catch a few errors. If the datafiles are created by a script this would be a useful addition to it.

Chris

For the 14e part of NFS@Home, work unit files, .fb and .ini are indeed created by a script, after being entered into a Web interface and stored into a relational DB. This interface and DB was created by squalyl for me in RSALS times, and imported into NFS@Home (then slightly improved, by e.g. producing .fb and .ini files directly), because I just couldn't imagine getting back to older, less automated methods :smile:

Checking whether the number is factored in FactorDB would be a useful addition to the Web interface's backend indeed. Two stronger validations would catch some, if not all, of the recent errors:
* checking whether the integer on the n: line divides the integer implied by the name (or explicitly entered into a new database column) and printing a notice if it doesn't;
* making a very short drive of factMsieve.pl / factmsieve.py / ggnfs-lasieve4I14e. If the number and polynomial don't match, those will barf.

Given that both Greg and I are pretty busy, maybe there should be human measures complementing the aforementioned computerized measures ? Thinking out loud: letting more persons access the Web interface for entering numbers, or going further (I know the idea was floated in RSALS times), splitting the functionality of the page between a more public part for entering candidate numbers, and a private page where admins would accept the numbers for queuing onto the grid and change their state ?

With the ever increasing computation power available to individual users on single computers, the 14e part of the grid will eventually disappear, but for now, we must keep it busy with tasks hard enough, e.g. GNFS difficulty ~155-~170 and SNFS difficulty ~225-~250 :smile:
Unless someone else wants to input more, easier numbers into the grid (I did myself at multiple periods in time), which gets us back to complementary human measures.

[QUOTE=VictordeHolland;386220]Yes, it's running a new 16GB memory kit (DDR3-2400), so I was suspecting that. I'll turn it down a notch to 2133 and see if the issue persists.[/QUOTE]

That is one way of going about things.
Another way of fixing the problem is fiddling with the memory or memory controller voltages.

[QUOTE=debrouxl;386250](snip)

Given that both Greg and I are pretty busy, maybe there should be human measures complementing the aforementioned computerized measures ? Thinking out loud: letting more persons access the Web interface for entering numbers, or going further (I know the idea was floated in RSALS times), splitting the functionality of the page between a more public part for entering candidate numbers, and a private page where admins would accept the numbers for queuing onto the grid and change their state ?

With the ever increasing computation power available to individual users on single computers, the 14e part of the grid will eventually disappear, but for now, we must keep it busy with tasks hard enough, e.g. GNFS difficulty ~155-~170 and SNFS difficulty ~225-~250 :smile:
Unless someone else wants to input more, easier numbers into the grid (I did myself at multiple periods in time), which gets us back to complementary human measures.[/QUOTE]

I would definitely appreciate the ability to submit numbers for consideration. Maybe set a minimum size (say C150 or C155) and request 1/3rd ECM (so a t50 or t55)? Along with the number itself, perhaps the submitter could include a short blurb about what importance the number has (i.e., HomePrimes or Aliquot sequence or whatever).

If I were allowed to submit a small number of ECM-pretested 14e candidates to the queue, I would be happy to solve matrices for any public jobs that can fit on a 8GB i7 laptop. A typical job is 20% ECM, 60% sieve, 20% matrix; is it reasonable to open up the queue for things like aliqueit sequences for some of us who do those 20%'s ourselves?

[QUOTE=debrouxl;386250]For the 14e part of NFS@Home, work unit files, .fb and .ini are indeed created by a script, after being entered into a Web interface and stored into a relational DB. This interface and DB was created by squalyl for me in RSALS times, and imported into NFS@Home (then slightly improved, by e.g. producing .fb and .ini files directly), because I just couldn't imagine getting back to older, less automated methods :smile:

Checking whether the number is factored in FactorDB would be a useful addition to the Web interface's backend indeed. Two stronger validations would catch some, if not all, of the recent errors:
* checking whether the integer on the n: line divides the integer implied by the name (or explicitly entered into a new database column) and printing a notice if it doesn't;
* making a very short drive of factMsieve.pl / factmsieve.py / ggnfs-lasieve4I14e. If the number and polynomial don't match, those will barf.

Given that both Greg and I are pretty busy, maybe there should be human measures complementing the aforementioned computerized measures ? Thinking out loud: letting more persons access the Web interface for entering numbers, or going further (I know the idea was floated in RSALS times), splitting the functionality of the page between a more public part for entering candidate numbers, and a private page where admins would accept the numbers for queuing onto the grid and change their state ?

With the ever increasing computation power available to individual users on single computers, the 14e part of the grid will eventually disappear, but for now, we must keep it busy with tasks hard enough, e.g. GNFS difficulty ~155-~170 and SNFS difficulty ~225-~250 :smile:
Unless someone else wants to input more, easier numbers into the grid (I did myself at multiple periods in time), which gets us back to complementary human measures.[/QUOTE]
Would it help if for the next batch I provide a .poly and / or a .fb file for each candidate? I'd create the former with a script already written for my own use and the latter with factMsieve.pl --- exactly the same as when I run NFS myself.

If you want to give me (limited) access to the web interface that could work well, as long as at least minimal instruction is given.

Paul