[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 2 Jul 2013 15:38:02 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: bug: wrong ETA in incremental mode
On 2 Jul, 2013, at 13:09 , Solar Designer <solar@...nwall.com> wrote:
> With bleeding-jumbo, I get this:
>
> $ ./john pw --format=Raw-SHA256-opencl -pla=1
> Device 1: Tahiti (AMD Radeon HD 7900 Series)
> Local worksize (LWS) 64, global worksize (GWS) 4194304
> Loaded 1 password hash (Raw-SHA256-opencl [SHA256 OpenCL (inefficient, development use mostly)])
> Press 'q' or Ctrl-C to abort, almost any other key for status
> 0g 0:00:00:23 3/3 (ETA: 15:03:51) 0g/s 18827Kp/s 18827Kc/s 18827KC/s jc099685..jp2fu9
> 0g 0:00:00:32 3/3 (ETA: 15:08:51) 0g/s 22931Kp/s 22931Kc/s 22931KC/s nbhohn7..seci2fea
> [...]
> 0g 0:00:15:50 3/3 (ETA: 23:38:51) 0g/s 26901Kp/s 26901Kc/s 26901KC/s vln0182..v12b&ff
> 0g 0:00:16:35 3/3 (ETA: 00:03:51) 0g/s 26957Kp/s 26957Kc/s 26957KC/s 04782m4rm..0352l200%
>
> Is it trying to say that it's going to complete within a day? That's
> unrealistic. This run is not supposed to complete at all, unless the
> password gets cracked.
So the percentage is muted but not the ETA, I've never seen that. Perhaps specific to batch-mode? I'll have a look - btw I also had the idea to change Incremental's get_progress() to use status.cands instead of the naive Jumbo-specific "try" counter. This should theoretically increase performance although I recall I did not see the expected slight drop when I implemented it. Actually if status.cands is usable you don't really have any reason not to implement it in core too.
magnum
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.
