[Opendnssec-develop] hsmspeed not optimal?

[Roy Arends]

Rick Zijlker wrote on 01/28/2010 10:33:46 AM:

> Hey Rick,
> 
> Actually I ran this test at SoftHSM. It just finished. Here's the log:

Rick, I build hsm-speed, of which ods-hsmspeed is derivative (which does 
the same thing as hsm-speed, but uses libhsm instead of direct pkcs11 
calls).

The idea is that you start with 1 thread and a certain number of 
iterations, say 10000. You note the speed, and you run again with a larger 
number of iterations. If the speed increases, you continue increasing 
iterations until it reaches its full potential.

When more iterations doesn't increase speed, increase threads. Same deal 
here, continue increasing threads until you get the highest speed.

Note: contrary to common believe, the amount of threads does NOT relate to 
the amount of cores. Hence, 8 threads might still be scheduled to two or 
three cores or so. The original hsm-speed contained 'forking' as well, but 
that has been left out of ods-hsmspeed. You can't assign threads or forked 
children to cores, it all depends on the kernel/cpu relation, and is thus 
highly platform and cpu dependent.  To circumvent that, you have to use 
the throttling I described above.

I do not know what has been changed between rc2 and rc3 at the moment (I 
have limited bandwidth to check, as I am on the road currently).

Hope this helps a bit.

Roy



> 
> --
> [root at signer2 ~]# ods-hsmspeed -r softHSM -i 500000 -t 8
> Opening HSM Library...
> Generating temporary key...
> Temporary key created: 4717225f27c412e6ce4a52700f8d0a5d
> Signing 500000 RRsets with RSA/SHA1 using 8 threads...
> Signer thread #0 started...
> Signer thread #2 started...
> Signer thread #1 started...
> Signer thread #4 started...
> Signer thread #3 started...
> Signer thread #5 started...
> Signer thread #6 started...
> Signer thread #7 started...
> Signer thread #7 done.
> Signer thread #5 done.
> Signer thread #1 done.
> Signer thread #3 done.
> Signer thread #6 done.
> Signer thread #0 done.
> Signer thread #4 done.
> Signer thread #2 done.
> Signing done.
> 8 threads, 500000 signatures per thread, 810.82 sig/s (RSA 1024 bits)
> Deleting temporary key...
> --
> 
> This with RC3. In RC2 I got towards 5000 sig/s with the same
> configuration so it feels like something is wrong. 
> It even slows down now when running more threads:
> 
> --
> [root at signer2 ~]# ods-hsmspeed -r softHSM -i 5000 -t 1
> Opening HSM Library...
> Generating temporary key...
> Temporary key created: 4d58758ce514f68cdd3dd2e543444927
> Signing 5000 RRsets with RSA/SHA1 using 1 thread...
> Signer thread #0 started...
> Signer thread #0 done.
> Signing done.
> 1 thread, 5000 signatures per thread, 1033.65 sig/s (RSA 1024 bits)
> Deleting temporary key...
> 
> [root at signer2 ~]# ods-hsmspeed -r softHSM -i 5000 -t 8
> Opening HSM Library...
> Generating temporary key...
> Temporary key created: 8bb75d13e51565000285fe9df3c8409e
> Signing 5000 RRsets with RSA/SHA1 using 8 threads...
> Signer thread #0 started...
> Signer thread #1 started...
> Signer thread #2 started...
> Signer thread #3 started...
> Signer thread #4 started...
> Signer thread #5 started...
> Signer thread #6 started...
> Signer thread #7 started...
> Signer thread #3 done.
> Signer thread #6 done.
> Signer thread #0 done.
> Signer thread #7 done.
> Signer thread #4 done.
> Signer thread #1 done.
> Signer thread #2 done.
> Signer thread #5 done.
> Signing done.
> 8 threads, 5000 signatures per thread, 823.79 sig/s (RSA 1024 bits)
> Deleting temporary key...
> --
> 
> 
> Cheers,
> Rick
> 
> 
> -----Original Message-----
> From: Rick van Rein [mailto:rick at openfortress.nl] 
> Sent: donderdag 28 januari 2010 16:25
> To: Rick Zijlker
> Cc: opendnssec-develop at lists.opendnssec.org
> Subject: Re: [Opendnssec-develop] hsmspeed not optimal?
> 
> Rick,
> 
> Inhowfar are you generating new keys?  We noticed that LUNA SA slows
> down immensely (it is craving for entropy, basically) wheres a
> continuous signing operation should be able to load it fully.
> 
> Slow keygen is good... it means that it takes entopy seriously.
> 
> Not sure if this helps, but perhaps it does.
> 
> -Rick
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20100129/0c184275/attachment.htm>