Hm .... now this is very (??) .. um ... "interesting" (note this is
stable 0,9.8-4squeeze1)
Assuming no silly user error, the code execution time has quite high
variability. High-level math and/or statistics is not my area of
expertise. However, given these results, do you agree it is plausible
your results are simply due to algorithm variability ? Can you test
multiple runs on a machine to which you have access ?
Executing four consecutive runs for each bit-size 256-4096 ...
----------------------------------
#! /bin/sh
RUNS=4
for BITS in 256 512 1024 2048 4096
do
for R in `seq 1 $RUNS`
do
time openssl dhparam -outform DER -5 -out parameters.dh $BITS >
/tmp/dh${BITS}.$R 2>&1
done
done
----------------------------------
Results (Yes -- this is relatively old box):
*** 256 ***
1) 0.03user 0.00system 0:00.08elapsed 46%CPU
2) 0.71user 0.00system 0:00.78elapsed 91%CPU
3) 0.54user 0.00system 0:00.57elapsed 93%CPU
4) 0.44user 0.00system 0:00.49elapsed 91%CPU
*** 512 ***
1) 5.45user 0.00system 0:05.50elapsed 99%CPU
2) 4.53user 0.01system 0:04.60elapsed 98%CPU
3) 8.89user 0.01system 0:08.94elapsed 99%CPU
4) 4.92user 0.00system 0:04.98elapsed 99%CPU
*** 1024 ***
1) 17.50user 0.02system 0:17.59elapsed 99%CPU
2) 5.81user 0.00system 0:05.88elapsed 98%CPU
3) 40.87user 0.02system 0:40.95elapsed 99%CPU
4) 47.88user 0.02system 0:47.97elapsed 99%CPU
*** 2048 ***
1) 21.57user 0.00system 0:21.64elapsed 99%CPU
2) 284.93user 0.02system 4:44.98elapsed 99%CPU
3) 206.71user 0.02system 3:26.74elapsed 99%CPU
4) 20.87user 0.00system 0:20.92elapsed 99%CPU
*** 4096 ***
1) 18903.08user 0.40system 5:15:02elapsed 100%CPU
2) Still running after 5h 10m
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
