Hello back, On Sat, Dec 04, 2010 at 11:30:39PM +0100, Lluís Batlle i Rossell wrote: > I attach the results I got in the nanonote, having openssl 1.0.0b built with > gcc > 4.5.1 (for a generic 32-bit system). > > Notice that the time measures at the last part of the benchmark get to 0.0s; I > have no idea why this happens.
I investigated the problem a bit. 'stracing', I saw that openssl uses the "times()" system call to get the user-mode time spent since it started the work and a SIGALRM came programmed by alarm(3). For usual cases, as openssl moves mainly user-mode code (cipher-related algorithms), the user-mode time difference should be around 3 seconds. strace showed that in the kernel I was using (2.6.35 openwrt trunk) times() reported an increasing user-time during the first ~11 minutes, and the kernel-mode time increased only a little (mainly due to writes to the terminal I imagine, and the other few syscalls like alarm/times involved). After ~11 minutes (around 64k jiffies), the user-time stalled, and all the jiffies got added into the kernel-mode jiffie counter. The value at which the user-time stalled was different at every run, but always around 64k. I could reproduce the problem also with gzip looking at the jiffie counters at /proc/PID/stat. So it was not related to openssl. barbes on irc checked the 2.6.32.10 qi-openwrt kernel, and he could not reproduce the problem. I built and run the 2.6.36 openwrt-trunk kernel, and there I also could not reproduce the trouble. And that is all I tested. So I leave it as a bug only in 2.6.35. Regards, Lluís. _______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
