Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 10 Mar 2010 02:44:20 +0100
From: "Magnum, P.I." <rawsmooth@...dband.net>
To: john-users@...ts.openwall.com
Subject: Re: Is JTR MPIrun can be optimized for more cores ?

RB skrev:
> On Tue, Mar 9, 2010 at 12:50, websiteaccess@...il.com
> <websiteaccess@...il.com> wrote:
>>  Why I get only 1558 more hashes cracked with 8 cores than 2 cores ???
> 
> Because of the way the current MPI implementation splits the work.  If
> you look at the log for an --incremental run, you'll notice JtR is
> splitting the password space up into 'passes' - length@...th.  Each of
> those passes is incrementally larger (harder) than the last.  The
> current MPI implementation splits work by these passes: the first
> process takes the first pass, the 2nd the 2nd pass, and so on.  When
> they complete a pass, they leapfrog to the next pass in their order -
> on a 4-processor run, the 2nd process will do passes 2, 6, and 10; the
> 3rd will do 3, 7, and 11, and so on.

That is certainly also true, and this will be increasingly significant 
after some time of running. For five-minute runs it doesn't have that 
much of an impact.

However, my oversimplified explanation is also relevant. The "test" as 
performed was completely flawed regardless of version of john. You could 
as well ask why incremental mode on standard JtR will give a constantly 
diminishing crack rate. A variant of WA's question is "Why do I get only 
10% more hashes cracked with twice the time?". This is common and has 
little to do with MPI.

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.