20211024, 23:43  #34  
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest
6,679 Posts 
Optimal prp proof power versus exponent
Re prime95 / mprime at least, assuming enough disk space is available, overallcomputeoptimal (proof & server & cert total effort) proof powers are thought to be, based on information provided by George Woltman, for some version v30.x of mprime/prime95, perhaps v30.3:
Quote:
And Quote:
Extrapolating higher, power 13 would cover optimal up to 414.2/106.5 * 6.2 G ~ 24. G, well past the maximum fft length 512 Mi of Mlucas v20.x which will support up to ~8.9 G exponent. And extrapolating as needed to go lower, than prime95's commonb.c source code provides (power 5): 420K  1.7M power 6 105K  420K power 5 ~26K  105K power 4 ~6.5K  26K power 3 ~1.6K  6.5K power 2 ~400  1.6K power 1 The crossover exponent values are somewhat dependent on program efficiency, so somewhat subject to change among mprime/prime95 versions, and across applications (gpuowl; eventually Mlucas). Recent attempts to rederive the proof power transition points for mprime/prime95 from program runs, source code examination, and cost function analysis have not duplicated the above, giving different results instead. Top of this reference thread: https://www.mersenneforum.org/showpo...89&postcount=1 Top of reference tree: https://www.mersenneforum.org/showpo...22&postcount=1 Last fiddled with by kriesel on 20220506 at 16:10 Reason: added dependency on program efficiency & rederivation 

20211113, 00:26  #35 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest
15027_{8} Posts 
Requirements for comparability of interim residues
To compare parallel long runs in progress, it is useful/necessary to have runs produce and preserve comparable interim results. Differences may indicate errors early. That is especially important for longer runs, and code relatively lower in error detection and correction. Standalone P1 factoring typically has less error detection. That is partly because less emphasis was placed on it due to shorter run time than primality testing for the same exponent. It's also partly because the number theory does not offer as many opportunities for error detection in standalone P1 factoring. (The Jacobi symbol check is more costly in P1 stage 1, because unlike for LL, we don't know the correct Jacobi symbol value; we must compute it, and compute the check on the interim results.) It's also partly because the impact of an error is lower in P1 stage 2, affecting only a small fraction of the stage, not the whole stage, or whole primality test as can occur in LL. However, in P1 factoring for F33 or OBD or higher Mersennes, P1 run times become months or years on typical fast hardware, increasing the importance of error detection.
In the context of GIMPS Mersenne prime searching, for P1 interim res64 matching between multiple runs on the same number, all the following must be present, which is more complex than required conditions for LL or PRP interim res64 matching: In P1 stage 1:
For P+1, ECM: no idea. P+1 random seed, ECM random curve parameter, would seem to make comparing runs more difficult and less necessary. For TF: interim residues are not output, so there's nothing to check. By comparison, for LL, it's simpler:
And for PRP (& PRPDC), it's a little more complicated again. With GEC, there is extremely reliable checking in progress, typically with automatic rollback and retry from the last saved confirmedgood state. The ability to compare and check any PRP iteration number's interim residue is likely to be needed by developers during debugging. This requires:
(Perhaps more to come. Including corrections.) A special thanks here to Ernst Mayer for considerable explanation by PM regarding P1. Constructive comments especially by software authors are invited. Top of this reference thread: https://www.mersenneforum.org/showpo...89&postcount=1 Top of reference tree: https://www.mersenneforum.org/showpo...22&postcount=1 Last fiddled with by kriesel on 20220415 at 19:10 Reason: minor formatting 
20211207, 15:54  #36 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest
6,679 Posts 
Exponent limits
Exponent limits of software and servers are tabulated by GIMPS computation type and application or server, in the attachments. Maximum exponent empirically confirmed is reliably 100% of nominal for TF, but varies from 20% to ~101% for other computation types.
Top of this reference thread: https://www.mersenneforum.org/showpo...89&postcount=1 Top of reference tree: https://www.mersenneforum.org/showpo...22&postcount=1 Last fiddled with by kriesel on 20220425 at 07:30 Reason: status update 
20220626, 17:11  #37  
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest
6,679 Posts 
Gerbicz Error Check block size
(draft; add links to development posts)
Note, some of this was originally posted at https://mersenneforum.org/showpost.p...postcount=2773 or elsewhere. The exponent is necessarily prime or there is no point to the PRP test. So GECblocksize > mod (exponent, GECblocksize) > 0. Quote:
Gpuowl Gpuowl allows as few as two blocks per GEC check, as at startup; l is not required to equal h. GEC block size is kept constant through the run on an exponent, and is often highly composite. The entire set of gpuowl PRP iterations are guarded by GEC by computing additional iterations to complete the last GEC block, up to and past the exponent. (IIRC Preda has explained this before.) For example, 77232917 / 1000 = 77232.917, so 77233 blocks of 1000 (77233000 iterations) would be used. The overhead of GEC is small, but such that larger than default blocksize computing a few more total iterations can actually be more efficient, if the reliability is high. (See end of this reference post.) From gpuowl help.txt: Code:
block <value> : PRP GEC block size, or LL iterationblock size. Must divide 10'000. Code:
20220626 12:52:53 gpuowl v6.11380g79ea0cc 20220626 12:52:53 config: user kriesel cpu asr2/radeonvii3w2 d 3 use NO_ASM maxAlloc 14000 cleanup block 1 proof 10 20220626 12:52:53 device 3, unique id '' 20220626 12:52:53 asr2/radeonvii3w2 216091 FFT: 128K 256:1:256 (1.65 bpw) 20220626 12:52:53 asr2/radeonvii3w2 Expected maximum carry32: 00000 20220626 12:52:53 asr2/radeonvii3w2 using long carry kernels 20220626 12:52:53 asr2/radeonvii3w2 OpenCL args "DEXP=216091u DWIDTH=256u DSMALL_HEIGHT=256u DMIDDLE=1u DPM1=0 DAMDGPU=1 DWEIGHT_STEP_MINUS_1=0x8.d305cfef9df78p5 DIWEIGHT_STEP_MINUS_1=0xd.d574837e195a8p6 DNO_ASM=1 clunsafemathoptimizations clstd=CL2.0 clfinitemathonly " 20220626 12:52:57 asr2/radeonvii3w2 OpenCL compilation in 3.85 s Assertion failed: blockSize >= 2, file Gpu.cpp, line 502 These have estimated GEC overhead (at p ~ 10^{8} IIUC) as follows: Code:
blksz l % overhead 1 200. 2 100. 4 50. 5 40. 8 32. 10 20. 16 12.5 20 10. 25 8. 40 5. 50 4. 80 2.5 100 2. 125 1.6 200 1. 250 0.8 400 0.5 500 0.4 625 0.32 1000 0.2 1250 0.16 2000 0.1 2500 0.08 5000 0.04 10000 0.02 In case of an error, a number of iterations corresponding to the log interval are repeated at least once: Code:
20220625 06:29:33 roa/radeonvii 852348659 OK 575720000 67.55%; 9737 us/it; ETA 31d 04:11; 2f21cdfbb27f9808 (check 11.47s) 49 errors 20220625 06:32:59 roa/radeonvii 852348659 EE 575740000 67.55%; 9726 us/it; ETA 31d 03:19; c9292397e8e476d9 (check 11.19s) 49 errors 20220625 06:33:12 roa/radeonvii 852348659 OK 575720000 loaded: blockSize 1000, 2f21cdfbb27f9808 20220625 06:36:38 roa/radeonvii 852348659 OK 575740000 67.55%; 9727 us/it; ETA 31d 03:25; 09a617fede5d61be (check 11.47s) 50 errors 20220625 06:40:04 roa/radeonvii 852348659 OK 575760000 67.55%; 9723 us/it; ETA 31d 03:01; e724dd1feb882e6e (check 11.46s) 50 errors Using too high a block size for the exponent produces few GEC checks and apparently causes proof generation to fail: Code:
20220626 13:38:17 gpuowl v6.11380g79ea0cc 20220626 13:38:17 config: user kriesel cpu asr2/radeonvii3w2 d 3 use NO_ASM maxAlloc 14000 cleanup block 2000 proof 10 log 20000 20220626 13:38:17 device 3, unique id '' 20220626 13:38:17 asr2/radeonvii3w2 216091 FFT: 128K 256:1:256 (1.65 bpw) 20220626 13:38:17 asr2/radeonvii3w2 Expected maximum carry32: 00000 20220626 13:38:17 asr2/radeonvii3w2 using long carry kernels 20220626 13:38:17 asr2/radeonvii3w2 OpenCL args "DEXP=216091u DWIDTH=256u DSMALL_HEIGHT=256u DMIDDLE=1u DPM1=0 DAMDGPU=1 DWEIGHT_STEP_MINUS_1=0x8.d305cfef9df78p5 DIWEIGHT_STEP_MINUS_1=0xd.d574837e195a8p6 DNO_ASM=1 clunsafemathoptimizations clstd=CL2.0 clfinitemathonly " 20220626 13:38:21 asr2/radeonvii3w2 OpenCL compilation in 3.89 s 20220626 13:38:21 asr2/radeonvii3w2 216091 OK 0 loaded: blockSize 2000, 0000000000000003 20220626 13:38:21 asr2/radeonvii3w2 validating proof residues for power 10 20220626 13:38:21 asr2/radeonvii3w2 Proof using power 10 20220626 13:38:22 asr2/radeonvii3w2 216091 OK 4000 1.83%; 97 us/it; ETA 0d 00:00; 63c70be5ec859db2 (check 0.15s) 20220626 13:38:23 asr2/radeonvii3w2 216091 OK 20000 9.17%; 105 us/it; ETA 0d 00:00; a51215284f0c1608 (check 0.15s) 20220626 13:38:26 asr2/radeonvii3w2 216091 OK 40000 18.35%; 126 us/it; ETA 0d 00:00; 9f69d4e111046456 (check 0.16s) 20220626 13:38:29 asr2/radeonvii3w2 216091 OK 60000 27.52%; 121 us/it; ETA 0d 00:00; 5614e1c31fc5b23a (check 0.15s) 20220626 13:38:31 asr2/radeonvii3w2 216091 OK 80000 36.70%; 107 us/it; ETA 0d 00:00; ba8e91ee8a118ae6 (check 0.15s) 20220626 13:38:33 asr2/radeonvii3w2 216091 OK 100000 45.87%; 98 us/it; ETA 0d 00:00; 0b51858a4a12ef62 (check 0.15s) 20220626 13:38:35 asr2/radeonvii3w2 216091 OK 120000 55.05%; 99 us/it; ETA 0d 00:00; 5098a06175e33b5e (check 0.15s) 20220626 13:38:37 asr2/radeonvii3w2 216091 OK 140000 64.22%; 100 us/it; ETA 0d 00:00; 67c044a637589727 (check 0.15s) 20220626 13:38:39 asr2/radeonvii3w2 216091 OK 160000 73.39%; 98 us/it; ETA 0d 00:00; f933c2a2638b1b9a (check 0.15s) 20220626 13:38:42 asr2/radeonvii3w2 216091 OK 180000 82.57%; 100 us/it; ETA 0d 00:00; 387e35fbbe410479 (check 0.15s) 20220626 13:38:44 asr2/radeonvii3w2 216091 OK 200000 91.74%; 99 us/it; ETA 0d 00:00; 7e58fc60c8cd8180 (check 0.15s) 20220626 13:38:45 asr2/radeonvii3w2 PP 216091 / 216091, 0000000000000001 Assertion failed: k > 0 && k <= topK, file ProofSet.h, line 281 Code:
20220626 13:03:13 gpuowl v6.11380g79ea0cc 20220626 13:03:13 config: user kriesel cpu asr2/radeonvii3w2 d 3 use NO_ASM maxAlloc 14000 cleanup block 5 proof 10 log 20000 20220626 13:03:13 device 3, unique id '' 20220626 13:03:13 asr2/radeonvii3w2 216091 FFT: 128K 256:1:256 (1.65 bpw) 20220626 13:03:13 asr2/radeonvii3w2 Expected maximum carry32: 00000 20220626 13:03:13 asr2/radeonvii3w2 using long carry kernels 20220626 13:03:13 asr2/radeonvii3w2 OpenCL args "DEXP=216091u DWIDTH=256u DSMALL_HEIGHT=256u DMIDDLE=1u DPM1=0 DAMDGPU=1 DWEIGHT_STEP_MINUS_1=0x8.d305cfef9df78p5 DIWEIGHT_STEP_MINUS_1=0xd.d574837e195a8p6 DNO_ASM=1 clunsafemathoptimizations clstd=CL2.0 clfinitemathonly " 20220626 13:03:17 asr2/radeonvii3w2 OpenCL compilation in 3.84 s 20220626 13:03:17 asr2/radeonvii3w2 216091 OK 0 loaded: blockSize 5, 0000000000000003 20220626 13:03:17 asr2/radeonvii3w2 validating proof residues for power 10 20220626 13:03:17 asr2/radeonvii3w2 Proof using power 10 20220626 13:03:17 asr2/radeonvii3w2 216091 OK 10 0.00%; 199 us/it; ETA 0d 00:01; 9da4a09b9023d001 (check 0.01s) 20220626 13:03:22 asr2/radeonvii3w2 216091 OK 20000 9.21%; 205 us/it; ETA 0d 00:01; a51215284f0c1608 (check 0.01s) 20220626 13:03:25 asr2/radeonvii3w2 216091 OK 40000 18.43%; 195 us/it; ETA 0d 00:01; 9f69d4e111046456 (check 0.01s) 20220626 13:03:30 asr2/radeonvii3w2 216091 OK 60000 27.64%; 206 us/it; ETA 0d 00:01; 5614e1c31fc5b23a (check 0.01s) 20220626 13:03:34 asr2/radeonvii3w2 216091 OK 80000 36.85%; 205 us/it; ETA 0d 00:00; ba8e91ee8a118ae6 (check 0.01s) 20220626 13:03:39 asr2/radeonvii3w2 216091 OK 100000 46.06%; 249 us/it; ETA 0d 00:00; 0b51858a4a12ef62 (check 0.02s) 20220626 13:03:46 asr2/radeonvii3w2 216091 OK 120000 55.28%; 365 us/it; ETA 0d 00:01; 5098a06175e33b5e (check 0.02s) 20220626 13:03:52 asr2/radeonvii3w2 216091 OK 140000 64.49%; 290 us/it; ETA 0d 00:00; 67c044a637589727 (check 0.01s) 20220626 13:03:56 asr2/radeonvii3w2 216091 OK 160000 73.70%; 208 us/it; ETA 0d 00:00; f933c2a2638b1b9a (check 0.01s) 20220626 13:04:00 asr2/radeonvii3w2 216091 OK 180000 82.91%; 205 us/it; ETA 0d 00:00; 387e35fbbe410479 (check 0.01s) 20220626 13:04:04 asr2/radeonvii3w2 216091 OK 200000 92.13%; 208 us/it; ETA 0d 00:00; 7e58fc60c8cd8180 (check 0.01s) 20220626 13:04:08 asr2/radeonvii3w2 PP 216091 / 216091, 0000000000000001 20220626 13:04:08 asr2/radeonvii3w2 216091 OK 217090 100.00%; 204 us/it; ETA 0d 00:00; 28d01226b9466041 (check 0.01s) 20220626 13:04:08 asr2/radeonvii3w2 proof: building level 1, hash 501ced7b2faed88c 20220626 13:04:08 asr2/radeonvii3w2 proof: building level 2, hash c6210f5fce31fa40 20220626 13:04:08 asr2/radeonvii3w2 proof: building level 3, hash b64b7be25a5b3f92 20220626 13:04:08 asr2/radeonvii3w2 proof: building level 4, hash f127ebdb12e4fbbc 20220626 13:04:08 asr2/radeonvii3w2 proof: building level 5, hash fe7a3beaf20377e2 20220626 13:04:08 asr2/radeonvii3w2 proof: building level 6, hash fe7ba158a7c29784 20220626 13:04:08 asr2/radeonvii3w2 proof: building level 7, hash cd55f7ef1e061d66 20220626 13:04:09 asr2/radeonvii3w2 proof: building level 8, hash 03a04903f6dcfbbf 20220626 13:04:10 asr2/radeonvii3w2 proof: building level 9, hash 0667a5e37d43bb0a 20220626 13:04:13 asr2/radeonvii3w2 proof: building level 10, hash a1a0233eb7bda91a 20220626 13:04:18 asr2/radeonvii3w2 PRPProof 'proof\21609110.proof' generated 20220626 13:04:18 asr2/radeonvii3w2 Proof: cleaning up temporary storage 20220626 13:04:19 asr2/radeonvii3w2 {"status":"P", "exponent":"216091", "worktype":"PRP3", "res64":"0000000000000001", "residuetype":"1", "errors":{"gerbicz":"0"}, "fftlength":"131072", "proof":{"version":"1", "power":"10", "hashsize":"64", "md5":"d46aad26ddc6adf4bec2a4b4051b7688"}, "program":{"name":"gpuowl", "version":"v6.11380g79ea0cc"}, "user":"kriesel", "computer":"asr2/radeonvii3w2", "timestamp":"20220626 18:04:19 UTC"} Code:
20220626 13:40:42 gpuowl v6.11380g79ea0cc 20220626 13:40:42 config: user kriesel cpu asr2/radeonvii3w2 d 3 use NO_ASM maxAlloc 14000 cleanup block 200 proof 10 log 20000 20220626 13:40:42 device 3, unique id '' 20220626 13:40:42 asr2/radeonvii3w2 216091 FFT: 128K 256:1:256 (1.65 bpw) 20220626 13:40:42 asr2/radeonvii3w2 Expected maximum carry32: 00000 20220626 13:40:42 asr2/radeonvii3w2 using long carry kernels 20220626 13:40:42 asr2/radeonvii3w2 OpenCL args "DEXP=216091u DWIDTH=256u DSMALL_HEIGHT=256u DMIDDLE=1u DPM1=0 DAMDGPU=1 DWEIGHT_STEP_MINUS_1=0x8.d305cfef9df78p5 DIWEIGHT_STEP_MINUS_1=0xd.d574837e195a8p6 DNO_ASM=1 clunsafemathoptimizations clstd=CL2.0 clfinitemathonly " 20220626 13:40:46 asr2/radeonvii3w2 OpenCL compilation in 3.84 s 20220626 13:40:46 asr2/radeonvii3w2 216091 OK 0 loaded: blockSize 200, 0000000000000003 20220626 13:40:46 asr2/radeonvii3w2 validating proof residues for power 10 20220626 13:40:46 asr2/radeonvii3w2 Proof using power 10 20220626 13:40:46 asr2/radeonvii3w2 216091 OK 400 0.18%; 113 us/it; ETA 0d 00:00; 99a8c14b82765acf (check 0.04s) 20220626 13:40:49 asr2/radeonvii3w2 216091 OK 20000 9.21%; 138 us/it; ETA 0d 00:00; a51215284f0c1608 (check 0.03s) 20220626 13:40:52 asr2/radeonvii3w2 216091 OK 40000 18.42%; 133 us/it; ETA 0d 00:00; 9f69d4e111046456 (check 0.02s) 20220626 13:40:54 asr2/radeonvii3w2 216091 OK 60000 27.62%; 110 us/it; ETA 0d 00:00; 5614e1c31fc5b23a (check 0.03s) 20220626 13:40:56 asr2/radeonvii3w2 216091 OK 80000 36.83%; 108 us/it; ETA 0d 00:00; ba8e91ee8a118ae6 (check 0.02s) 20220626 13:40:58 asr2/radeonvii3w2 216091 OK 100000 46.04%; 112 us/it; ETA 0d 00:00; 0b51858a4a12ef62 (check 0.02s) 20220626 13:41:00 asr2/radeonvii3w2 216091 OK 120000 55.25%; 107 us/it; ETA 0d 00:00; 5098a06175e33b5e (check 0.02s) 20220626 13:41:03 asr2/radeonvii3w2 216091 OK 140000 64.46%; 105 us/it; ETA 0d 00:00; 67c044a637589727 (check 0.02s) 20220626 13:41:05 asr2/radeonvii3w2 216091 OK 160000 73.66%; 106 us/it; ETA 0d 00:00; f933c2a2638b1b9a (check 0.02s) 20220626 13:41:07 asr2/radeonvii3w2 216091 OK 180000 82.87%; 102 us/it; ETA 0d 00:00; 387e35fbbe410479 (check 0.02s) 20220626 13:41:09 asr2/radeonvii3w2 216091 OK 200000 92.08%; 109 us/it; ETA 0d 00:00; 7e58fc60c8cd8180 (check 0.04s) 20220626 13:41:11 asr2/radeonvii3w2 PP 216091 / 216091, 0000000000000001 20220626 13:41:11 asr2/radeonvii3w2 216091 OK 217200 100.00%; 107 us/it; ETA 0d 00:00; 146b40888c95c7e9 (check 0.02s) 20220626 13:41:11 asr2/radeonvii3w2 proof: building level 1, hash 501ced7b2faed88c 20220626 13:41:11 asr2/radeonvii3w2 proof: building level 2, hash c6210f5fce31fa40 20220626 13:41:11 asr2/radeonvii3w2 proof: building level 3, hash b64b7be25a5b3f92 20220626 13:41:11 asr2/radeonvii3w2 proof: building level 4, hash f127ebdb12e4fbbc 20220626 13:41:11 asr2/radeonvii3w2 proof: building level 5, hash fe7a3beaf20377e2 20220626 13:41:11 asr2/radeonvii3w2 proof: building level 6, hash fe7ba158a7c29784 20220626 13:41:12 asr2/radeonvii3w2 proof: building level 7, hash cd55f7ef1e061d66 20220626 13:41:12 asr2/radeonvii3w2 proof: building level 8, hash 03a04903f6dcfbbf 20220626 13:41:13 asr2/radeonvii3w2 proof: building level 9, hash 0667a5e37d43bb0a 20220626 13:41:16 asr2/radeonvii3w2 proof: building level 10, hash a1a0233eb7bda91a 20220626 13:41:21 asr2/radeonvii3w2 PRPProof 'proof\21609110.proof' generated 20220626 13:41:21 asr2/radeonvii3w2 Proof: cleaning up temporary storage 20220626 13:41:22 asr2/radeonvii3w2 {"status":"P", "exponent":"216091", "worktype":"PRP3", "res64":"0000000000000001", "residuetype":"1", "errors":{"gerbicz":"0"}, "fftlength":"131072", "proof":{"version":"1", "power":"10", "hashsize":"64", "md5":"d46aad26ddc6adf4bec2a4b4051b7688"}, "program":{"name":"gpuowl", "version":"v6.11380g79ea0cc"}, "user":"kriesel", "computer":"asr2/radeonvii3w2", "timestamp":"20220626 18:41:22 UTC"} GEC was introduced to prime95 at v29.4. It does it differently, leaving unguarded the last few iterations past the last whole block up to the exponent. It also dynamically varies GEC block size up or down based on error rate observed, or downward for the last iterations left IIRC. So the number of unguarded iterations at the end is only dozens, with a low expected rate of error. From prime95's undoc.txt: Code:
When doing highlyreliable error checking, the interval between compares can be controlled with these two settings in prime.txt: PRPGerbiczCompareInterval=n (default is 1000000) Reducing the interval will reduce how far the program "rolls back" when an error is detected. It will also increase the overhead associated with errorchecking. NOTE: For technical reasons, PRPGerbiczCompareInterval is rounded to the nearest perfect square. ALSO NOTE: The program automatically adjusts the Gerbicz interval downward when an error is detected. This will reduce the amount of time "lost" rolling back to the last verified good iteration after an error is detected. Over time, the Gerbicz interval will be adjusted back upward after many successful compares. From a recent version's help.txt: Code:
The ITERS_BETWEEN_CHECKPOINTS value can be customized by adding a "CheckInterval = [value]" line to one's mlucas.ini file, but note that there are constraints on the value related to the Gerbiczchecking done for PRP tests. Specifically, the CheckInterval value must be a multiple of 1000 and must divide 1 million. Violation of these constraints will trigger an assertionexit if a PRPtest is attempted. Top of this reference thread: https://www.mersenneforum.org/showpo...89&postcount=1 Top of reference tree: https://www.mersenneforum.org/showpo...22&postcount=1 Last fiddled with by kriesel on 20220807 at 16:20 

Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
"The Librarians" on TNT ... Mersenne Prime reference  Madpoo  Lounge  6  20170131 20:03 
GPU Computing Cheat Sheet (a.k.a. GPU Computing Guide)  Brain  GPU Computing  20  20151025 18:39 
How do you obtain material of which your disapproval governs?  jasong  jasong  97  20150914 00:17 
NFS reference  Jushi  Math  2  20060828 12:07 
The difference between P2P and distributed computing and grid computing  GP2  Lounge  2  20031203 14:13 