BOINC NFS sieving - NFS@Home

[Mini-Geek]

Taking GC_6_302.

I've done a post-processing from NFS@Home with an Aliquot sequence number before, so I think I know what I'm doing. If I'm stepping on toes or otherwise doing something stupid by trying to post-process this number, feel free to stop me.

[swellman]

Originally Posted by pinhodecarlos

Just a side note, due to the introduction of the NFS@Home badges and the start of Formula Boinc 2014, NFS@Home had a good increase in work done. This is the reason you guys are so busy doing non stop post-processing tasks. Keep the factors coming!

Carlos

You weren't joking! It's like drinking from a fire hose.

Good stuff though. I'll reserve some more this week.

[pinhodecarlos]

Originally Posted by swellman

You weren't joking! It's like drinking from a fire hose.

Good stuff though. I'll reserve some more this week.

Why you though I was joking when I am a big supporter of the project? Right now I can't help due to bandwidth problems but I do every possible to bring more people to NFS@Home sieve. And if Greg increases the points per wu for all, like doubling, more people would come. There are BOINC projects out there that per wu take the same amount of time as the ones in NFS@Home but they score precisely double. Just a thought......

[swellman]

It's just a figure of speech. No criticism intended.

Impressive queue!

[debrouxl]

Thanks for taking on post-processing tasks
I recently gained limited access to a laptop equipped with Core i7-4700HQ, 8 GB DDR3-1600 RAM and a GTX-760M, but I don't think I'll be able to do much post-processing on it. The airflow is mild to poor, anyway: Prime95 TF or stress-test bring core temperature above 90°C...

I keep being no fan of inflating WU credit in an artificial arms race between projects.

[Mini-Geek]

Originally Posted by Mini-Geek

Taking GC_6_302.

I've done a post-processing from NFS@Home with an Aliquot sequence number before, so I think I know what I'm doing. If I'm stepping on toes or otherwise doing something stupid by trying to post-process this number, feel free to stop me.

Linear algebra on this has begun, but the matrix is larger than I had anticipated. Compared to a recent c161 GNFS (log file is attached there) I post-processed, this SNFS has fewer unique relations, but a much larger matrix (log file attached).

The ETA is currently about 320 hours (13.35 days) running on 4 threads of an i5-750. So, is there something wrong here, or is this normal for an SNFS of this size?

My guesses are either: for equivalent sieving difficulty, SNFS post-processing is harder than GNFS post-processing, or using 30 bit instead of 29 bit makes post-processing harder, or this number is quite undersieved (there were 16,967 bad relations; more than I'd hope, but not enough to dent the 110M raw relations).

[pinhodecarlos]

I think the issue here is the old processor you are using, it is from the first generation of the i5 series. You should not run any post-processing.
Look at this example of L1803, harder number than yours, using an old version of msieve without taking advantage of the 50 % speed up and it was less than 13 days.

[pinhodecarlos]

Sorry but I can't attach the log file, I am having issues with my internet connection. I've been trying to do that for the last half an hour. Also lost remote control of all my machines at the lab. Stupid country!

[fivemack]

Sat Feb  8 22:00:43 2014  prp66 factor: 404675335237566634047776648973783207303326616897166891987863934321
Sat Feb  8 22:00:43 2014  prp130 factor: 1696730016839592422643861847045769083116586949070298346176899128778077851774931860994847291623499641743091454357450360253615261427

(this is on an 27-inch late-2009 iMac, so a 2.66GHz i5-750; the calculation took three days and two hours)

The problem Mini-Geek is having is that GC_6_302 hasn't really been adequately sieved; GC_3_493 was

Wed Feb  5 18:29:55 2014  found 23759882 hash collisions in 114929460 relations
Wed Feb  5 18:32:37 2014  found 23918010 duplicates and 92230841 unique relations
Wed Feb  5 19:19:36 2014  weight of 7866793 cycles is about 881162366 (112.01/cycle)
Wed Feb  5 19:40:09 2014  matrix is 7866504 x 7866793 (3440.3 MB) with weight 1007198370 (128.03/col)
Wed Feb  5 19:46:12 2014  matrix is 7861747 x 7861995 (3309.9 MB) with weight 854233213 (108.65/col)
Wed Feb  5 19:46:12 2014  sparse part has weight 789062072 (100.36/col)
Wed Feb  5 19:46:12 2014  using block size 8192 and superblock size 786432 for processor cache size 8192 kB
Sat Feb  8 21:16:56 2014  BLanczosTime: 266001

so my 92.2M unique relations allowed a much kinder matrix than Mini-Geek's 84.7M. (Note that I did msieve -nc1 target_density=112 to produce a denser matrix; but that's not enough to make the difference between my 7.8M and Mini-Geek's 13.5M)

[fivemack]

Sun Feb  9 10:51:44 2014  prp77 factor: 64009584216674889468458818694189952605977464081091106962702687045133335779049
Sun Feb  9 10:51:44 2014  prp145 factor: 8554780841752594133475867349359594755953859533742822341879655839115512478425071586100240422814547272554917378482675533036850453079886122821118929

7.4M sparse-weight 101.3 matrix; 24 hours on i7/4930K -t6

The ready-for-post-processing queue is now empty - it looks as if a few more mega-Q were pushed last night to get weights down. Excellent.

[Mini-Geek]

Originally Posted by fivemack

The problem Mini-Geek is having is that GC_6_302 hasn't really been adequately sieved

Based on this and some PM discussion, I'm unreserving GC_6_302, at least for the time being. Thanks for the help.