[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150311175649.GA17322@openwall.com>
Date: Wed, 11 Mar 2015 20:56:49 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: [GSoC] building JtR for MIC
On Thu, Mar 12, 2015 at 12:41:15AM +0800, Lei Zhang wrote:
> I'm finally able to build john-jumbo for MIC. It can run on MIC now, but still has some problem. I'll describe the building process first, and then how it runs.
Great!
Could you please post patches or make a pull request on GitHub
corresponding to your changes to get jumbo to build and work on MIC?
> When I started building, I found there're some libraries that are required by john-jumbo but not natively available on MIC. They are OpenSSL, GMP and Zlib. I had to download and build them for MIC manually, which also took me a while.
I think we'll need to have this described in a README-MIC file or/and
have it scripted.
We may also distribute a tarball with jumbo and these libraries
pre-built for MIC.
> With all library dependencies resolved, there're still some source files that failed to compile.
Please share with us your patches to get these to compile.
> Will run 240 OpenMP threads
> Benchmarking: descrypt, traditional crypt(3) [512/512]... (240xOMP) DONE
> Many salts: 3744K c/s real, 30881 c/s virtual
This is 20x+ slower than the performance I reported here:
http://www.openwall.com/lists/john-dev/2015/03/05/2
Your other benchmark results are also slower than they should be, but
not by that much.
Are you using this MIC card exclusively, or is it running some other
code at the same time?
You need to figure out this unexpected slowness. It might be related to
other issues you'd be running into, such as the one with scrypt:
> Benchmarking: scrypt (16384, 8, 1) [Salsa20/8 32/64]... (240xOMP) Killed
> -------------------------------------------------------------------------
>
>
> It seems the process got killed when running ???scrypt???. I'm still looking for the cause of this problem.
> Suggestions are welcome.
scrypt is special in that it needs much memory. Our test vectors appear
to require up to 16 MB. For 240 threads, that's just below 4 GB. Since
your 5110P has 8 GB RAM, it should probably successfully run this test,
but maybe much of its RAM is occupied by something else? e.g. some large
files uploaded to its RAM filesystem, or someone using it concurrently?
The "Killed" diagnostic is consistent with the out-of-memory theory.
The MIC card's Linux kernel's OOM killer was likely triggered.
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
