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.