[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <819a61b10606012342i5bf73673i66a32c619369bbe0@mail.gmail.com>
Date: Fri, 2 Jun 2006 08:42:24 +0200
From: "Otheus (aka Timothy J. Shelling)" <otheus@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: Re: beta MPI john patch against 1.7.2.
Solar, thanks for the in-depth reply... Just a few notes...
Yes, there were rejects on the Makefile, even with "patch -l". I had to
> fix those manually and re-generate the patch before placing it for
> download. Please use the following command for generating patches for
> subsequent revisions of your code:
>
> TZ=UTC diff -urp john-1.7.2 john-1.7.2-mpi >
> john-1.7.2-mpi-tjs-2.diff
>
> The "-2" will be the patch revision number - you'll increment it each
> time you generate a new patch for the same base version of John. If you
> add any new files, you'll need to add the "-N" option to diff as well.
Understood.
Also, your john.conf has lots of unrelated changes. It is a good idea
> to revert those.
User notes: "the john.conf provied should be *incorporated* into your
john.conf."
SHould I maybe provide a patch to john.conf in this case?
The same suggestions apply to any other patches I place in contrib/ -
> which is why I am posting them to the mailing list.
>
> > Known bugs:
> > o john.pot gets littered with extraneous output, usually low integers
> > like "4" or "1" and a newline. Very strange. Still trying to track it
> down.
>
> My previous guess (from the private e-mail) proves correct - you do in
> fact close stdout and stderr in your patch. While you try to re-open
> stderr, the way you do it is not guaranteed to work right. And I don't
> see you re-opening stdout at all. So those numbers are some debugging
> output being printed to either stdout or stderr - perhaps they are
> MPI_rank's?
I knew you would bring this up --it's a red herring. I added that code only
late last night while I was doing some fine-tuning with the option parsing.
I t cnanot possibly have anything to do with the earlier behavior. I and I
don't close stdout (except in --test) mode, where it's irrelevant.
> o internalized computing the checksum for ext_word. 15% increase in
> speed
> > (at least)
>
> > o use of external filter with internal checksum causes a slight
> (1-2%)
> > slowdown
>
> You can't reasonably speak of speedups/slowdowns by a certain percentage
> unless you mention the hash type and the number of different salts for
> which you did your benchmarks.
--incremental mode, salted DES3.
On Wed, May 31, 2006 at 11:30:14PM +0200, Otheus (aka Timothy J. Shelling)
> wrote:
> > On synchronizing crypts/salts between all tasks, another thought
> occurred to
> > me. After every checkpoint, simply load in the john.pot file (assuming
> it's
> > not corrupted ;) ). Would that be a simpler, (though slightly less
> optimal),
> > approach?
>
> Yes, that would work - as long as you have that file shared between the
> tasks anyway.
It is shared. Is there a function which rebuilds the database using the new
john.pot file and restarts the word--generation, etc?
I'll address optimization stuff more as a I get the chance.
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.
