Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 18 Mar 2015 17:27:45 +0800
From: Lei Zhang <zhanglei.april@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: [GSoC] building JtR for MIC

Hi,

I tweaked with OMP_SCALE in several formats, according to magnum's advices, and their memory usage on MIC is much more reasonable now. With OpenMP enabled, john-jumbo won't abort anymore when running the benchmark, although 126 of the tests still FAILED.

Next I want to figure out how those tests failed, but I have a few questions first: (forgive me if they look stupid...)
1. What exactly does it mean for a format to FAIL the test?
2. There're two kind of numbers in the output, real and virtual. What's their difference?


Thanks,
Lei


> On Mar 18, 2015, at 12:22 AM, magnum <john.magnum@...hmail.com> wrote:
> 
> On 2015-03-17 10:38, Lei Zhang wrote:
>> I reran the benchmarks on MIC, with or without OpenMP, and got some statistics.
>> 
>> *With OpenMP:*
>> The result is a bit different from last time. The program didn't get killed when 
>> running /mschapv2-naive/, but aborted later when running /mysql/, with error 
>> message: *****mem_alloc(): Cannot allocate memory trying to allocate 5190451200 
>> bytes*****
> 
> Wow that's pretty heavy for a single allocation. Note the following
> lines in mysql_fmt_plug.c:
> 
> #define OMP_SCALE			81920
> (...)
> #define MAX_KEYS_PER_CRYPT		8
> 
> This is your problem. You will ending up allocating 81920*8*240*33 bytes
> for the plaintext buffer (btw the "33" is [PLAINTEXT_LENGTH + 1]).
> 
> So this OMP_SCALE is obviously not suitable for MIC. Try something like this
> 
> + #ifdef __MIC__
> + #define OMP_SCALE			128
> + #else
>   #define OMP_SCALE			81920
> + endif
> 
> Then you may tweak it by doubling it until it doesn't get faster (or
> just gets silly high).
> 
> Nearly all OpenMP formats use this exact scheme so you can fix most
> formats the same way. I'm pretty sure the NETLM* and NETNTLM* formats
> are just as bad or worse.
> 
> magnum
> 
> 

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ