bogus timing calculation in gcrypts benchmark

Tobias Ulmer tobiasu at
Sun Mar 7 00:14:49 CET 2010

Hi there,

I've had a look at the catastrophic results of gcrypt on BSD systems
posted here:

It turns out that this is due to a number of bugs in benchmark.c.
It uses CLOCKS_PER_SEC, which on BSD systems is the actual tick rate,
but on "XSI conformant" systems, it's always 1000000. (Have a look into
bits/time.h on a glibc system, the definition violates ANSI C...).

The second bug is the "ms" unit, I guess it should haven been "us".

If we assume that the unit is microseconds, then there's a 0 too many in
the scaling factor.

So here's a patch that should be as portable as it gets, with a sane
millisecond resolution. Tested on OpenBSD and Linux


PS: please CC

--- tests/benchmark.c.orig	Thu Apr  2 11:25:34 2009
+++ tests/benchmark.c	Sat Mar  6 23:40:05 2010
@@ -27,6 +27,7 @@
 #ifdef _WIN32
 #include <windows.h>
+#include <unistd.h>
 #include <sys/times.h>
@@ -332,8 +333,9 @@
   t = (t2 - t1)/10000;
   snprintf (buf, sizeof buf, "%5.0fms", (double)t );
+  long ticks = sysconf(_SC_CLK_TCK);
   snprintf (buf, sizeof buf, "%5.0fms",
-            (((double) (stopped_at - started_at))/CLOCKS_PER_SEC)*10000000);
+            (((double) (stopped_at - started_at))/ticks)*1000);
   return buf;

More information about the Gcrypt-devel mailing list