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
Powered by Openwall GNU/*/Linux - Powered by OpenVZ