Karl Fogel <kfogel@red-bean.com> writes:
> "Justin Erenkrantz" <justin@erenkrantz.com> writes:
>> I'm running it under oprofile to see if something jumps out, but I
>> doubt that the CPU or HDD differences should account for 20 seconds
>> vs. 1:30 for basic_tests - something else is going on. And I know
>> it's not entropy-based as the times are consistent between
>> /dev/urandom and /dev/random. -- justin
>
> In IRC just now, I did some testing for Justin on my own machine:
>
> - http://www.red-bean.com/kfogel/thinkpad-r60-debian.html
> - HEAD of Subversion trunk
> - Python 2.4.4
> - subversion/tests/cmdline/svn-test-work mounted as ramdisk
>
> Timing just basic_tests.py over ra_local, we saw:
>
> With /dev/random:
> real 3m40.892s
> user 0m10.793s
> sys 0m7.792s
>
> With /dev/urandom:
> real 0m16.539s
> user 0m9.517s
> sys 0m7.108s
>
> It's amazing what the addition of one little letter 'u' can do!
Karl, do you have the development files for libuuid installed?
Looking at the APR code I see that it will use the system uuid
generator if that is available, and fall back on it's own algorithm
otherwise. On my machine APR uses the system uuid generator which
uses /dev/urandom even though APR itself uses /dev/random. That means
that my system doesn't stall generating uuids, so ra_local tests run
without a problem, it only stalls when doing the ra_svn CRAM stuff.
Thus I only need to make APR use /dev/urandom when running the ra_svn
tests.
I guess Karl's machine isn't using the system libuuid, so configuring
APR to use /dev/urandom affects UUID generation and speeds up the
ra_local tests.
If Justin's machine is using the system libuuid and if that libuuid is
configured to use /dev/random then his machine will drain entropy and
stall even when APR is configured to use /dev/urandom. Running
strace -etrace=open svnadmin create dummy
should confirm it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 3 22:57:08 2007