[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140717142031.GA15028@openwall.com>
Date: Thu, 17 Jul 2014 18:20:31 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: CPU stats on multi-core?
On Tue, Jul 15, 2014 at 10:41:42PM -0500, Richard Miles wrote:
> I played a bit more with my CPU using the --fork option and I'm a bit
> unsure if it's working properly. I tried for example some unix MD5 hashes
> on 8 cores and I get this stats:
Are these for wordlist mode? What's the wordlist size? Do you have
rules enabled? How many rules are there? You might want to take a look
at the log file - it should say whether JtR is currently distributing
rules or words between the fork'ed processes. Normally, it starts by
distributing rules while it has enough of them, and then switches to
distributing words when there are too few rules left to distribute.
> 0g 0:05:28:22 15.17% (ETA: 2014-07-01 23:11) 0g/s 6729p/s 20189c/s 20189C/s
> 1lucyusza..1lucyutopia
> 0g 0:05:28:22 18.76% (ETA: 16:17:04) 0g/s 6755p/s 20266c/s 20266C/s
> mrusignuolo2..mrusilowicz2
> 0g 0:05:28:22 2.32% (ETA: 2014-07-10 07:00) 0g/s 6837p/s 20511c/s 20511C/s
> babyelloe2009..babyellysya
> 0g 0:05:28:22 20.52% (ETA: 13:46:56) 0g/s 6750p/s 20252c/s 20252C/s
> mrkuiapu!..mrkuiorzdw!
> 0g 0:05:28:22 32.68% (ETA: 03:51:30) 0g/s 6666p/s 20000c/s 20000C/s
> lavatod6..lavatoghji6
> 0g 0:05:28:22 0.04% 0g/s 7370p/s 22112c/s 22112C/s *)%^!&#&..*)%^!&%&
> 0g 0:05:28:22 4.15% (ETA: 2014-07-05 22:59) 0g/s 6817p/s 20451c/s 20451C/s
> Cancox03786..Cancox03804
> 0g 0:05:28:22 16.10% (ETA: 2014-07-01 21:06) 0g/s 6862p/s 20588c/s 20588C/s
> 4WIJNPIJP..4WIJNRANKEN
BTW, these lines are normally prefixed with job number (should be
numbers from 0 to 7 in your case). I wonder why these numbers are not
shown for you.
Some discrepancies between progress percentages are to be expected.
A primary reason why --fork is generally faster than OpenMP in terms of
c/s rate is that it doesn't synchronize the jobs. However, what you
show above does look weird to me... but please see below for possible
reasons.
> Well, I assume that each ETA is per virtual core, correct? If not, it could
> complete more than 100% sum them all together.
Each of these should get to 100% individually, skipping over candidate
passwords that other jobs test.
> The weird thing is, all my virtual cores are exactly the same,
As you can see, the c/s rates for them are in fact similar.
> why they have too much discrepancy from one to another?
Two main possibilities are:
1. They started at different places in the ruleset, and you have a low
number of rules (close to the number of processes). (I wonder what the
reported percentages were when you just started this session.)
2. An integer overflow occurred when calculating those percentages.
> I don't have other applications or programs running, however, we see for
> example some cores that executed only 0.04% while other executed 32.68%.
More correctly, one is reported to be at 0.04% and another at 32.68%
within the total set of candidate passwords to try. This doesn't
necessarily mean the job reported as 32.68% has actually processed this
percentage so far - it may have started e.g. at 32.64%, if that's what
occurred after distributing a small number of rules to your jobs (my
guess is that having around 21 rules would cause reporting like this).
The job reporting 0.04% is probably doing the very first rule, so it
started at 0%. The job reporting 32.68% might be doing the 8th rule.
You can find out for sure from the log file. Yes, I can see how this
can be very confusing.
> Very weird, I was expecting them all to run pretty close one to the other.
And they do, if you look at the c/s rate.
> Is there a way to fix it?
This weird reporting doesn't always occur, but when it does there's no
way to fix it currently (yet continue to use --fork). I suggest that
you consider the percentages and ETAs as extremely rough estimates,
which might not be right.
> Is there a way to print a single stat line for all cores? I think it would
> be less confusing.
Currently, this is only possible with OpenMP. You may in fact try
rebuilding with OpenMP support. Did you explicitly disable it now?
I ask because bleeding-jumbo's ./configure enables it by default.
When you run with OpenMP instead of --fork, there will be just one
status line. The drawbacks are slightly lower c/s rate and higher
sensitivity to any other load you might have on the system (OpenMP is
affected by other load badly, whereas --fork mostly doesn't care).
Oh, and higher impact on performance of other processes, since with
--fork JtR uses idle cycles only (by default), whereas with OpenMP that
setting is overridden (since it'd have greater impact on JtR's speed).
Right now, you're getting over 164k c/s cumulative for those 8 jobs.
Try OpenMP and compare the c/s rate to that figure. I expect you'll get
a c/s rate over 150k c/s, and possibly over 160k c/s, as long as your
system is otherwise idle. This might be good enough for you.
(Note that for other other hash types the performance penalty of OpenMP
over --fork is greater. But with md5crypt it's small, so you're lucky.)
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.
