[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <34e2a064dfbd0ef10c7e2351096b732a@smtp.hushmail.com>
Date: Tue, 2 Jul 2013 16:54:05 +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 15:38 , magnum <john.magnum@...hmail.com> wrote:
> 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.
Oh, I am seasoned: It was indeed specific to batch mode - the 3/3 was read as 3% done. In unstable, the batch mode indicator is shown as (3) which was handled correctly because it doesn't start with a figure. So this was introduced with the 1.8 core merge (my bad - I'm not *that* seasoned :-)
> 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.
I did this now too. Much cleaner and restoring is handled by core code instead of the Jumbo hack. Like I feared it actually resulted in a slight performance drop... but I will ignore that - dropping a memory variable that is incremented at *every* call to crk_process_key() just has to be a good thing.
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.
