The problem on the server was due to an out of space condition, so I guess there are several hundred thousands of garbled bytes at some point. But I'd have expected this to occur around (from memory) 10.6/13.7 of the file, i.e. something more like 150M raw relations ?

The server seems to be up at the time of this writing, and to have been up continuously since ~8 a.m. CET.

I'm done with 457_83_minus1. 1021_79_minus1 LA will take me some 163 hours.
I would like to reserve 479_79_minus1 but I am not sure if it is a 28 or 29 bits tasks, Lionel? Is 1049_67_minus1 already for post-processing? I'm trying to feed a dual-core laptop with a 28 bits task....

479_79_minus1 is a 28-bit LPs task, probably not oversieved much (with the current range of q values). I suggest waiting until at least three quarters of the estimated 800K remaining raw relations are returned :smile:

[QUOTE=debrouxl;284496]479_79_minus1 is a 28-bit LPs task, probably not oversieved much (with the current range of q values). I suggest waiting until at least three quarters of the estimated 800K remaining raw relations are returned :smile:[/QUOTE]

I think I'll go for 1049_67_minus1 or 1061_67_minus1, both SNFS difficulty lower than 479_79_minus1.

1021_79_minus1 can be moved to to the "postprocessing" state.

About 479_79_minus1 it needs more relations.

OK, queued 40M-45M. I guess I stretched the usage of 28-bit LPs a bit too far for this one...

251_97_minus1
 

[code]prp58 factor: 5825443069319148300454148330348066853170101505386932384637
prp161 factor: 13063394551937604983694439905137886535055013102913412399293119363547684372200927448371734206968923374888454677477080254879460063486922321378165949227404293717579[/code]

Paul

Thanks :smile:

I'm going for 1061_67_minus1. Downloading the files right now. It will be run on a dual-core laptop...lol

That's what I used for 1049_67_minus1 (marginally easier than 1061_67_minus1), and it took less than 15h to produce ~2.43M cycles and manipulate them :wink: