[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20070605223000.GB28155@openwall.com>
Date: Wed, 6 Jun 2007 02:30:00 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: "Idle" setting: system responsiveness and performance
On Tue, Jun 05, 2007 at 10:12:16AM +0100, Evo Eftimov, iSec Consulting, www.isecc.com wrote:
> If Idle=N will the user interface of the system become unresponsive
No, but it will feel slower. I recommend "Idle=Y" for almost all uses
of John, with the only exception being benchmarks. There's almost no
difference in performance of John itself between these two settings when
running on a system with no similar load. Server-type load is OK, and
"Idle=Y" helps reduce (in fact, almost eliminate) the impact John would
otherwise have on server response times. The same applies to uses of
John on a PC or workstation. I'll try to explain:
When a request arrives to a server (e.g., for a web page) or you do
typical work on a PC or workstation (e.g., start a GUI application that
needs to display its window), processing of such a request (received
from the remote client or initiated by you) will take a certain amount
of processor time. That amount of processor time is almost constant
(for a given computer), and, with no idle CPU available, it will be
taken away from John regardless of the "Idle" setting. With "Idle=Y"
and no idle CPU available, John will pause its work while the
interactive request is being handled - so the request is handled quicker
(in terms of real time). With "Idle=N" and no idle CPU available, John
will compete for CPU time with handling of the interactive request -
resulting in the request taking longer to be handled (again, in terms of
real time). Yes, John will "win" some CPU cycles for itself during that
time - but by doing so it will increase the duration of this "fight".
So in the long run it will not advance any further than it would if it
paused gracefully.
When there is in fact an idle CPU available (on a multi-CPU system), the
"Idle" setting makes no difference.
One thing I did not mention in the simplified description above (but I
do mention it briefly now) is that the "fight" for CPU time often has an
impact on the efficiency of caches. So the lack of a "fight", when John
is configured with "Idle=Y" and thus it waits for the request to be
handled, might actually result in slight performance increase for all
tasks that would otherwise compete for CPU time (and cache space).
When there's other load that is in fact similar to John's and the number
of CPU cores is smaller than the number of threads that cause such load,
things are different. With "Idle=N" and no special scheduling priority
settings for any of the processes or threads, each thread is likely to
get an equal share of CPU time. With "Idle=Y" and no other special
scheduling priority settings for any of the other processes or threads,
John will almost stop (and stay that way) and let the other tasks run,
which is probably not what you want.
On systems with SMT (simultaneous multithreading) processors, with Intel
Pentium 4 with Hyperthreading and Sun UltraSPARC T1 ("Niagara") being
two examples, the effect of "Idle" is less obvious and more OS-specific.
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: 5B341F15 fp: B3FB 63F4 D7A3 BCCC 6F6E FC55 A2FC 027C 5B34 1F15
http://www.openwall.com - bringing security into open computing environments
--
To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply
to the automated confirmation request that will be sent to you.
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.
